From: Christian Leber (christian_at_leber.de)
Date: 05. Feb 2000
>> Mittlerweile grüble ich auch, ob man den MP3-Kodierungsschritt
>> (außer zur Archivierung) nicht gleich weglassen kann.
>Ist sinnvoll, denn ich denke nicht, daß Du die mp3 unterbrechungsfrei
>kodieren könntest. Bin nicht so der mp3-Freak, aber wie schnell sind
>die Encoder, die man so bekommt?
Ich hab jetzt mal ein paar Tests gemacht:
und zwar das encoden einer 47.776.220 Byte großen WAV Datei 44.1 khz 16 bit
(4 min 30 sec)
Auf einem Pentium mit 166Mhz, Linux 2.2.14, GCC 2.95.2
1.) lame 3.51 (128 kbit/s) : real:11:13|user:10:16|sys:0:2
mit den im Makefile fuer den egcs empfohlenen Optimierungen
(außer march=pentium) real:10:12|user:9:21|sys:0:1
also ist das Verhaeltnis play/encode-time zwischen 0,40 und 0,44
Besser wird das ganze mit GOGO, einem Lame fork (von 3.2 aber es sind auch
Teile von der Lame dev Version enthalten, allerdings weiss ich nicht wie nah
das ganze an Lame ist, da die Dokumentation von GOGO mir primaer japanisch
erscheint... ist sie wohl auch, ich wuerde allerdings den Unterschied zu
koreanisch oder aehnlichem nicht merken ;))
Das Encoden mit 96 oder 64 kbit/s bringt keine Geschwindigkeitsvorteile.
gogo_2.25
128 kbit/s: (gogo sagt: 335.52sec) time: 6:14|5:33|0:3
64 kbit/s: (gogo sagt: 326.110sec) time: 5:55|5:21|0:5
die play/encode time liegt also bei 0,72
64kbit/s bringt auch hier nur geringe Geschwindigkeitsunterschiede
Schneller wird es auf einem PII/308, da dauert es 1 min 41 sec, also >2,4.
Das Problem bei der Sache ist jetzt, wenn das auf einem Alpha laufen soll,
dann ist es nichts mit GOGO...
es koennte recht schnell sein, zumindest heisst es ja immer, dass Alpha´s
eine schnelle FPU haben...
Ab einem PII/300 wird es auch mit Lame ca. in Echtzeit klappen.
Etwas bitter ist bei der Sache, dass die Ergebnisse bei Lame sich
unterscheiden ob man lame mit oder ohne Optimierung compiliert (also die
entstehenden mp3 Dateien unterscheiden sich).
>Wie leistungsstark ist der Rechner (Vergleich mit i386-Hardware)?
>Der Encoder müßte die Komprimierung schneller als "Echtzeit" schaffen,
>wenn "on-the-fly" komprimiert werden soll.
Nicht unbedingt, man kann sich ja nicht gleich alles auf einmal anhoeren...
sinnvoll waere es wohl zB. sich einen buffer zu basteln das auch in eine
Datei auslagern kann oder so, oder man schreibt jew. 1 Stunde Radio in einer
Datei und encoded diese dann.
>Frage (so aus Neugier): Könnte man nicht einen "normalen" Streamer
>dazu verwenden, Langzeitaufnahmen zu machen?
Wenn er soweit runterbremsen kann, dann schon, sonst man buffer, dass der
Streamer nicht so oft schreiben muss.
Viel interessanter als Radio zu digitalisieren und dann zu encoden waer aber
imo eine ganz andere Sache, naemlich den MPEG Layer2 Datenstrom(afaik 192
kbit/s) irgendwie aus einem ADR Receiver rauszubekommen, das wuerde wohl
wirklich gute Qualitaet ergeben und wenig Rechenleistung erfordern.
Gruss
Christian Leber
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET