Post by Marcel MuellerPost by Peter J. HolzerPost by Marcel MuellerWenn die MP3s schon kaputt sind, hat man keine Chance.
Allerdings sind die Lücken durch inexakt geschnittene MP3 Frames und
Encoder/Decoder-Latenz eher klein verglichen mit denen, die entstehen,
dadurch dass die Datei erst gelesen wird, wenn das letzte Sample
gespielt wurde.
Von welchen Latenzen reden wir da? Bei einer rotierenden Harddisk kann
das Öffnen eines Files und Lesen des ersten Blocks schon mal eine
zweistellige Anzahl Millisekunden dauern. Bei SSDs sollte das deutlich
unter einer Millisekunde sein.
- Mehrere Zugriffszeiten auf das IO-System. Man darf nicht vergessen,
dass bei MP3 die Metadaten am Ende stehen können, und selbst wenn nicht,
guckt eigentlich jeder Player da nochmal nach.
Das wären dann schätzungsweise noch einmal zwei Seeks. Ähnlich viel wie
zum Öffnen des Files.
Post by Marcel Mueller- Einmal die FIFO-Puffer vom Sounddevice. Das sind auch zweistellige ms.
Das sollte aber im der umgekehrten Richtung wirksam sein und
die Lücke zwischen dem Ende des vorigen Files und dem Anfang des neuen
schließen oder zumindest kürzen.
Post by Marcel Mueller- Je nach System dauert auch das Initialisieren der Sound-Pipeline für
eine bestimmte Sampling-Rate noch etwas. Falls dazu Resampling
erforderlich ist, fügt das auch nochmal Latenz hinzu (oder schlechte
Qualität).
Hmm. Ich nehme an, das kann man nicht machen, während noch Daten in der
Pipeline sind? Das wäre dann eine Lücke, die man auf jeden Fall hört
(wenn das Reinitialisieren und Wiederauffüllen der Pipeline lang genug
dauert, um hörbar zu sein).
Post by Marcel Mueller- Dann noch Dekodier-Zeit für die ersten Frames - üblicherweise eher klein.
- Dann die Encoder/Dekoder-Latenz. MP3 spuckt am Anfang des
Dekodier-Prozess erst mal Stille aus, bis alle Encoder- und
Decoder-Puffer und Filterbänke gefüllt sind. Wenn die Datei keine
Informationen zur Encoder-Latenz enthält, kann der Player diese nicht
sinnvoll verwerfen. Das sind auch zweistellige ms.
Das klingt nach einer inhärenten Schwäche des MP3-Formats aus, bei der
der Player nicht viel machen kann (höchstens Stille am Anfang eines
Tracks überspringen, aber die kann auch beabsichtigt sein).
Post by Marcel Mueller- Last but not least Padding. MP3s können nur ganze Frames enthalten.
Dadurch wird die Datei beim Encoden hinten immer mit Null-Samples
aufgefüllt, bis es passt. Wenn die Datei keine Informationen über das
tatsächliche Ende enthält, werden auch die wiedergegeben.
Auch das klingt nach einem Problem des MP3-Formats.
Post by Marcel MuellerPost by Peter J. Holzer(Bei CDs kann es natürlich deutlich länger dauern, vor allem, wenn das
Laufwerk erst anlaufen muss.)
Üblicherweise laufen CD-Laufwerke schon, wenn sie gerade den Track davor
gespielt haben. ;-)
Bei Audio-CDs schon. Aber wenn das z.B. MP3s auf einem ISO-9660-Filesystem
sind, dauert das Lesen des Files ein paar Sekunden. Bis dann das File
fertig abgespielt ist, vergehen ein paar Minuten und inzwischen könnte
der Treiber entscheiden, dass er das Laufwerk wieder stoppen sollte,
weil es ja keine Zugriffe mehr gibt. Und wenn der Player dann das
nächste File öffnen will, muss der Treiber das Laufwerk erst wieder
auf Touren bringen.
(Praktisch aufgefallen ist mir das vor ein paar Monaten beim Zusammenspiel
von Thunar (Filemanager von XFCE) und VLC. Thunar zeigt die einzelnen
Tracks einer Audio-CD als .wav-Files an (keine Ahnung, ob das ein Feature
des Kernel-CD-ROM-Treibers oder des Filemanagers ist). Wenn man alle
"Files" markiert und VLC aufruft, heult das CD-ROM-Laufwerk beim Start
jedes Tracks kurz auf und legt sich dann wieder zur Ruhe. Die Gaps
sind dann wirklich störend lang und das Geräusch des mit voller
Geschwindigkeit laufenden Laufwerks hilft auch nicht ...)
hp
