Was wollt ihr mit Handbrake/RipBot/...? Im Endeffekt nutzen alle den gleichen Encoder.
@ CB: Nehmt bei der Videocodierung lieber x264 (x265 falls es mal irgendwann gut/final wird) mit nem ordentlichen CRF (18 - 22 im Durchschnitt taugt für gutes Material in 1080p bei geringer Größe). 2pass ist immer zweckfrei, außer man will den Content auf ne bestimmte Größe quetschen. Filme/Videos will man aber primär in guter Qualität, die Größe steht da ganz hinten an und ist nur für Omas DVD-Player von Relevanz. 1080p mit 24p und 4k mit ggf. 60 FPS wären gut. 4k mit 24p/30 FPS wären mir aber auch genug, dann weiß ich was ich zukünftig an Zeit brauche. Evtl. auch mal in VP9 reinschnuppern zwecks Videos im Internet. Aber was nicht große Relevanz hat...
Audiocodierung wäre schön ja. Lossless (FLAC - ALAC, WavPack, WMA Lossless und Co. lass ich mal aus, denn die Performance (En- sowie Decodierung) und Kompression von FLAC ist schon sehr gut) -> Lossy (MP3/OPUS/AAC). OGG Vorbis lass ich mal weg, denn prinzipiell steckt es mit in OPUS und für die Zukunft ist das eher von Relevanz als das alte Vorbis, wenngleich es auch noch genutzt wird. Ggf. längere Stücke (1+ h) und (einige?) Alben konvertieren. Geht ja relativ zügig mittlerweile mit allen Encodern.
Hierbei (Video + Audio) bitte aber drauf achten
sinnvolle Mess- und Vergleichswerte darzulegen! Heißt: Gesamtdauer falls nötig und bitte bitte bitte das Encoding in Realtime, wie es immer so nett angegeben wird mitgeben. Kurzum: 10x Realtime bei CPU A gegen 12x Realtime bei CPU B. Es bringt mir viel mehr, wenn ich auf einen Blick sehe, wie schnell die CPU alles abarbeitet, anstatt ein langes Balkendiagramm zu haben, was mir aufzeigt wie lange CPU C an Stück D mit E min. geackert hat. Verkompliziert alles nur. Die Prozentangaben beim Hover sind da nur ne Abhilfe für ein Problem, was man hätte bereits lösen können.
Excel ist ne gute Idee, da wird die CPU bei großen Spreadsheets enorm gefordert und spätestens mit 2k13 ist auch ne solide Hardwarebeschleunigung dabei.
Das Wichtigste zum Schluss: Mir egal wie ihr das macht: Es nervt höllisch CPUs verschiedener Generationen zu vergleichen! Man hat einen aktuellen Test, sucht sich eine CPU aus, nimmt einen Test mit seiner CPU, sucht sich wieder ne CPU aus und wenn die beide vorhanden sind, kann man nen Vergleich anstellen. Ist das nicht der Fall, muss man sich noch nen dritten Test mit diesen jeweils zwei CPUs angeln, damit man indirekt über drei Tests die Performance von seiner aktuellen CPU und einer Neueren vergleichen kann.
Pro getestete Anwendung natürlich... Graut die doch einfach mit nem Vermerk aus und gut ist, aber so hat man wenigstens eine kleine Basis, auch wenn man das alles nicht zu 100 % vergleichen kann. Immerhin ist was Vergleichbares vorhanden. Oder macht ein Rundungszeichen davor, schreibt irgendwo Schätzung dahinter o.ä. Gerade heutzutage sinnvoll, denn keiner kauft sich heute noch jedes (/zweite) Jahr ne neue CPU.
@ Nerdovic:
Code:
$ ffmpeg -codecs | grep 264
DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_crystalhd h264_vdpau ) (encoders: libx264 libx264rgb )
Absoluter Nonsens irgend ein Frontend dafür zu nutzen und dabei ist es egal ob es durch ein Frontend wie ffmpeg, Handbrake, RipBot oder via Frontend + Frameserver (MeGUI) gejagt wird.
@ Jesterfox: IO-Last im CPU-Test? Halt ich für extrem fragwürdig. Vielleicht in ner großen RAM-Disk, aber selbst da... Hier gehts ja um CPU-Performance, nicht wann die HDD/SSD/RAM-Disk/SD-Karte "zusammenbricht". Dann lieber die fixeste CPU nutzen und das dann bei Laufwerktests anschneiden, da wo die IO-Performance im Rampenlicht steht. Außerdem ist das Compilen doch eh auf Single-Core-Leistung ausgelegt. Mehrere Threads helfen da kaum, außer dass mehrere Jobs gleichzeitig ausgeführt werden könn(t)en. Maßgeblich ist trotzdem die Pro-Kern-Leistung.
@ 3D-Mark und sonstige synthetische Tests: Komplett raus lassen. Was bringts mir zu wissen, wenns im 3D-Mark x Punkte gibt und aber jedes Spiel anders auf die CPU reagiert (CPU-lastige Games anyone?
). Genauso bringts mir nicht ansatzweise etwas, wenn ich weiß, dass man mit CPU Z prinzipiell mehr Daten durch den Bus schaufeln kann. Im Endeffekt limitiert doch eh wieder was anderes. Zumal man sich die theoretischen Daten auch aus dem Produktblatt ziehen kann. Weitere Befehlssätze machen den Kohl dann nochmal fetter, wenn plötzlich die vierfache Menge an Befehlen abgearbeitet werden kann, wobei die vorherige Generation nur zwei schaffte. Das seh ich dann aber auch im Real-World-Szenario, dafür brauchts keinen theoretischen Test.