Oder geht nur mir das so auf meinen ollen 1Ghz-Thunderbird-Systemen?

Musepack = 80 x
OGG, Mp3 und FLAC = 50 x
Wavepack = 25 x

Screenshots kann ich nachreichen, falls Interesse daran besteht.

welche oggenc2-aoTuV-Version läuft auf einem Pentium D (am besten)? Die P3- oder die P4-Version?

Grüße
blue box jelly fish

Optimierter FLAC Encoder
Optimierter MPEG ALS Encoder

Alle Codecs werden sehr schnell decodiert und sind damit beim Abspielen völlig unkritisch. Als am schnellsten hat sich hier MPC erwiesen, jedoch sind die drastisch anmutenden Unterschiede bei nur 15 bis 35 Sekunden Decodier-Zeit pro Album in der Praxis nicht relevant, zumindest nicht bei einem aktuellen Prozessor. Einschalten von Dithering verringert die Geschwindigkeit deutlich, sie ist aber zum Abspielen noch ausreichend schnell. Lediglich beim Brennen von Audio-CDs ist kein Decodieren in Echtzeit möglich, dem sollte ein Brennprogramm mit einem kleinen Zwischenspeicher jedoch problemlos entgegenwirken können, geht es doch insgesamt nur um Unterschiede von ca. 10 Sekunden zwischen Brenndauer und Decodierdauer.

Der Test wurde auf einem Pentium 4 3.0C Prozessor durchgeführt. Gemessen wurde übrigens mit dem in foobar2000 integrierten Decoding Speed Test, aufrufbar im Kontextmenü von Playlist-Einträgen unter Utils | Decoding speed test.

Wir haben zu diesem Thema ein paar Geschwindigkeitstests durchgeführt und möchte diesen Thread dazu nutzen, mit euch Erfahrungen und Ergebnisse auszutauschen um zu sehen, inwieweit bestimmte Prozessoren oder Betriebssysteme beim Encodieren im Vorteil sind, und wie sich die verschiedenen Encoder im Vergleich untereinander schlagen. Benchmarks bekannter Hardwareseiten berücksichtigen meistens nur LAME, seltener Ogg Vorbis, zu den hier auf AudioHQ beliebteren Formaten wie Musepack oder FLAC sind mir keine Tests bekannt, so dass es dem Anwender auch etwas schwerfällt sich für die richtige CPU für diesen Einsatzzweck zu entscheiden.

Auf der anderen Seite kann die Geschwindigkeit natürlich auch Auswirkungen auf die Wahl des Audioformates haben, wer eh nur am PC Musik hört und bei wem 170-200 kbps formatunabhängig transparent sind, der kann sich gerade anhand solcher Eigenschaften wie z.B. der Geschwindigkeit sein Lieblingsformat heraussuchen. Zeit ist Geld und das "Encodieren über Nacht" das man aus früheren Zeiten vielleicht noch kennt möchten sich heute wahrscheinlich die wenigsten noch antun.

Bei der Wahl der Encoder haben wir uns entschlossen, die jeweils für ein bestimmtes System schnellste Version zu bevorzugen, sprich auf bestimmte Prozessoren hin optimierte Compiles. Welches jeder konkret eingesetzt hat könnt ihr in den individuellen Kommentaren weiter unten nachlesen, die Versionsnummern sind aber bei allen die gleichen. Bei den Einstellungen fiel die Wahl auf diejenigen, die in den Codecartikeln als "Archivqualität" gekennzeichnet sind, in der Regel sind dies die Standardeinstellungen:

Format      Encoder  Einstellung
----------  -------  -----------------
FLAC        1.1.1    -5
Musepack    1.15s    --quality 5
Ogg Vorbis  1.1      -q 6
MP3:LAME    3.96.1   --preset standard

Damit sind auch gleichzeitig die getesteten Formate genannt, mehr war für uns zunächst nicht interessant.

Die Ergebnisse (zuletzt aktualisiert am 05.12.2004, 08:10), sortiert nach dem Durchschnitt:

Prozessor            FLAC    MPC     Vorbis  LAME    übermittelt durch
-------------------  ------  ------  ------  ------  -----------------
AMD Athlon 64 3400+    77.3    28.2    36.2    12.6  Benjamin
Intel Pentium 4 3.0    70.0    23.0    28.1    10.1  Frank
Intel Pentium 4 2.4    44.9    16.9    21.2     7.7  Spunky
AMD Athlon XP 2600+    47,2    19.5    13.0     7.9  DAU
AMD Athlon XP 2000+    46.0    17.1    12.8     8.1  Lenz
AMD Sempron 2800+      39.0    19.6    12.6     7.1  jergar
AMD Athlon XP 2100+    42.3    16.5    10.5     6.6  Ganymed
AMD Athlon XP 1900+    35.2    15.2    16.5     7.9  fischdarm

Zur Testmethodik: jeder von uns hat sich für seinen Hörgeschmack typische Beispiele - Einzeltracks oder ganze Alben - herausgesucht und encodiert. Die einzelnen Encodiergeschwindigkeiten wurden aufsummiert und anschließend durch die Anzahl getesteter Samples dividiert, um zu den in der Tabelle angegebenen Geschwindigkeitswerten zu gelangen. Um die Encodierdauer zu ermitteln könnt ihr dieser Anleitung folgen.

Ziel dieses Threads ist es übrigens nicht, möglichst exakte Encodiergeschwindigkeiten in aller Genauigkeit zu bestimmen, sondern lediglich Richtwerte zu ermitteln wie sie in der Praxis auftreten. Uns ist bewusst, dass die Messergebnisse durch viele Einflussfaktoren verfälscht werden können. Hierzu gehören unter anderem Betriebssystem, Schnelligkeit der Festplatte, Gesamtgeschwindigkeit des Systems, nebenbei laufende Anwendungen und nicht zuletzt natürlich die Eingabedateien, mit denen man die Messung durchführt. Diese Einflüsse wollen wir mal vernachlässigen, eine gewisse Unschärfe ist also durchaus gewollt, da sie auch in der Praxis auftritt.

Wie eingangs angekündigt hoffen wir nun natürlich auf Berichte von euren Erfahrungen auf verschiedenen System, damit ein runderes Bild entsteht. Teilt uns eure Messergebnisse für die vier Formate und Einstellungen bitte unter Nennung des von euch verwendeten Testsystems mit. Bitte haltet euch dabei an die Vorgaben, gerade auch was die Versionen anbelagt. Wir werden sie daraufhin in der Tabelle gegenüberstellen. Wer möchte, der kann in seiner Antwort auch ein persönliches Fazit vornehmen, auf das wir an dieser Stelle verzichten.

Wir bedanken uns gleichzeitig bei allen, die das bereits getan haben.

- Spunky, Lenz, Ganymed, Lego, Frank

Erstellen Sie sich eine Datei mit der Endung .bat, z.B. encode.bat. Diesen Dateityp nennt man Batchdatei und wer DOS nicht mehr kennt, dem sei gesagt, dass diese Dateien eine Folge von Befehlen enthalten die nacheinander ausgeführt werden. Genau das nutzen wir aus, wir automatisieren den Encodierprozess dadurch etwas.

Inhalt der Datei:

@echo off
echo %time% Starte FLAC Encoder...
for %%I in (*.wav) do flac.exe -5 --totally-silent "%%I" "%%~nI.flac" & call showtime "%%~nI.flac"
echo.
echo %time% Starte MPC Encoder...
FOR %%I in (*.wav) do mppenc.exe --quality 5 --silent "%%I" & call showtime "%%~nI.mpc"
echo.
echo %time% Starte Ogg Vorbis Encoder...
for %%I IN (*.wav) do oggenc.exe -q 6 -Q "%%I" -o "%%~nI.ogg" & call showtime "%%~nI.ogg"
echo.
echo %time% Starte LAME MP3 Encoder...
for %%I IN (*.wav) do lame.exe -V 2 --vbr-new --silent "%%I" "%%~nI.mp3" & call showtime "%%~nI.mp3"
echo.
pause

Erstellen Sie eine zweite Datei showtime.bat mit folgendem Inhalt:

@echo %time% %1

Sie wird die aktuelle Uhrzeit sowie den Dateinamen der gerade encodierten Datei ausgeben.

Bevor Sie den Test starten, stellen Sie bitte sicher, dass folgende Voraussetzungen erfüllt sind:

1. * alle zu encodierenden WAV-Dateien liegen im gleichen Ordner
   * die gewählten Encoder-Versionen entsprechen unseren Vorgaben
   * alle Kommandozeilen-Encoder und ebenfalls die beiden angelegten .bat-Dateien liegen ebenfalls in diesem Ordner
   * die Dateinamen der Encoder stimmen mit denen in der ersten Batchdatei überein

Sollte dies der Fall sein, dann können Sie den Test mit einem Doppelklick auf die obere Batchdatei (in meinem Fall encode.bat) starten, alternativ kann man sie auch über die Kommandozeile (Start | Ausführen - cmd) ausführen. Wer die Ausgabe in ein Textdatei umlenken will, der benutzt einen Befehl in der Form encode > encode.log.

Die Ausgabe sieht dann wie folgt aus:

15:50:19,39 Starte FLAC Encoder...
15:50:22,70 "01.flac"
15:50:25,73 "02.flac"
15:50:30,14 "03.flac"
15:50:34,46 "04.flac"

15:50:34,48 Starte MPC Encoder...
15:50:46,29 "01.mpc"
15:50:56,78 "02.mpc"
15:51:10,78 "03.mpc"
15:51:23,78 "04.mpc"

15:51:23,78 Starte Ogg Vorbis Encoder...
15:51:37,71 "01.ogg"
15:51:50,10 "02.ogg"
15:52:07,03 "03.ogg"
15:52:22,57 "04.ogg"

15:52:22,57 Starte LAME MP3 Encoder...
15:52:38,68 "01.mp3"
15:52:53,70 "02.mp3"
15:53:14,39 "03.mp3"
15:53:32,26 "04.mp3"

Drücken Sie eine beliebige Taste . . .

Es erfordert nun ein wenig Geschick mit Excel oder einem anderen geeigneten Tabellenkalkulationsprogramm, um die Encodierdauer zu erfassen und anschließend die Länge der Testdateien durch die Encodierdauer zu dividieren um den Geschwindigkeitswert zu erhalten.

Für auf bestimmte Weise zusammenhängende Dateien, z.B. solche eines Albums, empfehlen wir ihnen, Laufzeit und Encodierdauer dieser Dateien zu summieren und anschließend zu dividieren, bei der Betrachtung von Dateien aus verschiedenen Quellen, beispielsweise Einzeltracks oder mehrere Alben dagegen, zunächst die Geschwindigkeit für jede Datei/jedes Album zu ermitteln und anschließend einen Mittelwert zu bilden.

in diesem Bereich möchten wir die Geschwindigkeit verschiedener Encoder, Decoder, Versionen, Compiles und nicht zuletzt auch Systemkonfigurationen (Prozessor, Betriebssystem usw.) vergleichen. Dazu hoffen wir auf eure Teilnahme.

Fertig sind bereits:
* Vergleich verschiedener Encoder bei Archivqualität
* Anleitung zur Durchführung solcher Tests
* Analyse zwischen LAME 3.90.3 und 3.96.1
* Messungen der Decodiergeschwindigkeit

In Arbeit befinden sich:
* Betrachtung des Einflusses von Hyperthreading (neuere Pentium 4 Prozessoren)
* von unserer Seite sonst erstmal nichts weiter

Tests auf anderen Seiten:
* another lossless performance comparison, ...but on classical music only (guruboolez)
* Performance comparison of lossless audio compressors (Speek)
* Compression and speed of lossless audio formats (Hans Heijden)
* Tests von lossy Codecs gibt es nur bei uns ;)

Rein qualitativ können die beiden Versionen als gleichwertig bezeichnet werden, womit sich die Entscheidung an anderen Kriterien orientiert. Diese habe ich versucht in einer Messreihe in Zahlen zu fassen und in Anlehnung an die Hörtests auf HydrogenAudio die Encodierungsgeschwindigkeit und Komprimierungsgrad (anhand der durchschnittlichen Bitrate) gemessen. Außerdem habe ich verschiedene Genres gewählt (Classical, Folk, Heavy Metal, Hip-Hop (Rap), Jazz, Rock/Pop, Rock'n'Roll, Techno und Live-Versionen), um zu untersuchen, ob diese einen Einfluß besitzen.

Auf HydrogenAudio wurden folgende Vergleichstests durchgeführt:
Test 1 = 3.96 --p extreme vs. 3.90.3 --ap extreme
Test 2 = 3.96 --p extreme vs. 3.96 -V 1
Test 3 = 3.96 --p standard vs. 3.90.3 --ap standard
Test 4 = 3.96 -V 5 vs. 3.96 --p 128
Test 5 = 3.96 -V 5 vs. 3.90.3 --ap 128
Test 6 = 3.96 --p 128 vs. 3.90.3 --ap 128
Test 7 = 3.96 -V 5 vs. 3.96 -V 5 --athaa-sensitivity 1
Test 8 = 3.96 --p cbr 128 vs. 3.90.3 --ap cbr 128

Entsprechend dazu habe ich die Werte für Encodierungsgeschwindigkeit und Komprimierung ermittelt. Die komplette Auswertung im Excel-Format könnte Ihr bei Interesse hier herunterladen.

Dateigröße bzw. durchschnittliche Bitrate:

Bei der Dateigröße/Bitrate hatte ich die große Hoffnung, dass 3.96.1 besser abschneiden würde, aber diese Hoffnung konnte in den Tests leider nicht bestätigt werden. In Punkto Dateigröße liegen die beiden Lame-Versionen nahezu gleichauf.

Bei -preset standard ist zwar die Bitrate von 3.96.1 um ca. 3% geringer, viel ist das aber nicht. Einen Zusammenhang zwischen den Hörtests auf Hydrogen Audio und der Dateigröße konnte ich bei -p standard nicht ermitteln.

Bei 3.96.1 -V 5 vs. 3.90.3 --ap 128 ist die Bitrate im Schnitt bei 3.96.1 um ca. 5% größer als bei 3.90.3. Insgesamt, war das Bild der Hörtests uneinheitlich, die beiden Versionen können somit in dieser Einstellung als gleichwertig betrachtet werden. Hier scheint es jedoch einen Zusammenhang zwischen den Hörtests (Qualität) und Bitrate zu geben. Alle Samples, bei denen laut Hörtest 3.96 -V 5 besser war als 3.90.3 --ap 128 war auch die Bitrate bei 3.96 -V 5 größer als bei 3.90.3. Genauso das Verhalten bei Samples, wo 3.96 -V 5 schlechter bewertet wurde als 3.90.3 --ap 128, dann war die Bitrate der 3.96 kleiner.

3.96.1 -V 5 --athaa-sensitivity 1 wurde im Vergleich zu 3.96.1 -V 5 bei den Hörtests auf Hydrogen Audio durchweg besser bewertet. Die Bitrate ist dabei bei --athaa-sensitivity 1 im Schnitt um ca. 2% größer. Wer also -V5 verwendet, für den ist --athaa-sensitivity 1 durchaus interessant.

Bringt man 3.96.1 -V 5 --athaa-sensitivity 1 in Verhältnis zu 3.90.3 --ap 128 so kann man auch hier davon ausgehen, dass 3.96.1 -V 5 --athaa-sensitivity 1 wohl etwas besser sein dürfte. Dies kostet aber in Summe ein Plus von 7% bei der Dateigröße, womit die bessere Qualität auch keine großartige Überraschung ist.

Encodierungsgeschwindigkeit:

Bei der Encodierungsgeschwindigkeit hat 3.96.1 klar die Nase vorne. Bei gleicher Einstellung (extreme, standard, -preset 128 und -prest cbr 128) ist 3.96.1 im Schnitt um ca. 45% schneller als 3.90.3.

Die -V Einstellungen scheinen mehr Rechenkapazität zu benötigen als die "herkömmlichen" Presets. Zum Beispiel ist -V 5 im Vergleich zu --p 128 um ca. 33% langsamer (beides mit 3.96.1), sogar 3.90.3 ist mit --ap 128 schneller als -V 5.

Ein Blick auf die Genres:

Auffallend ist, dass besonders Jazz und Rock'n'Roll mit geringeren Bitraten encodiert werden können. Bei diesen Genres habe ich hauptsächlich sehr alte Aufnahmen gewählt (z.B. alte Beatles-Alben). Wo genau hier der Unterschied zu neuen Alben liegt, kann ich aber nicht beantworten.

Besonders hohe Bitraten werden bei Live-Versionen erzeugt, was auch nicht weiter verwundert, da Applaus und Kreischen hohe Anforderungen stellen. Auch Classical und Heavy Metal liegen in der Regel überhalb der Durchschnittsbitraten.

Ins Auge sticht weiterhin, dass die eben gemachten Aussagen nicht für 3.96.1 --p128 und 3.90.3 --ap128 gelten. Diese verhalten sich bezüglich Durchschnittsbitrate völlig gegensetzlich zu den anderen Einstellungen. Sogar Live-Alben brauchen weniger Bitrate als der Durchschnitt aller Songs. Hat jemand hierfür eine Erklärung?

Testequipment:

- Intel P4 2,4 GHz
- ASUS P4B533 256 MB DDR

Fazit:

3.96.1 ist bei gleicher Einstellung schneller als 3.90.3. Bei --p standard und --p extreme erzeugt 3.96.1 eine geringfügig kleinere Durchschnittsbitrate als 3.90.3, der Unterschied ist aber eher vernachlässigbar.

Spunky