2017-12-19 50 views
1

Ich spiele MP3-Datei mit Android-Mediaplayern. Aber wenn ich nach einer zufälligen Zeit mit seekTo (msec) -Funktion suche, zeigt jeder Spieler in jedem Android-Gerät leichte Unterschiede. Der Unterschied ist in der Zeit ungefähr 1 Sekunde.MP3-Codec hat auch I/p-Rahmen?

Die Sache, die ich bin neugierig ist, dass Mp3 MPEG1 Audio-Codec hat auch ich Frame/P-Frame-Zeug? Ich weiß, es ist die Eigenschaft von Video-Codec, aber ich möchte wissen, ob Audio-Codec auch ähnliche Attribute hat, so dass es zu einer Position springen muss, um I-Frame Audio zu dekodieren. Wenn dies der Fall ist, ist es vernünftig, dass ein solches Attribut Suchzeitunterschiede verursachen kann, da jeder Spieler nicht genau zur gleichen Zeit gestartet ist.

Antwort

1

Es gibt drei separate Probleme, die Sie wahrscheinlich treffen.

Die erste ist die MP3-Frame-Größe. (Dies ist anders als ein Video "Frame" ... denken Sie einfach an Frame in diesem Fall als ein Stück von Samples, die in MP3 codiert sind.) Diese Frame-Größe wird in der Regel 1.152 Samples sein. Du kannst unterhalb dieses Levels suchen, aber es erfordert eine Decodierung unterhalb dieses Levels als erstes, und nicht alle Spieler werden das tun.

Das zweite Problem ist das Bit Reservoir. Frames benötigen nicht immer den gesamten Platz, und der Encoder kann zurückgehen und sie mit Daten für andere Frames füllen, wobei er effektiv mehr Bandbreite verwendet, wenn er benötigt wird, während er innerhalb einer konstanten Bitrate bleibt. Ein naive Spieler sucht oft nach dem nächsten MP3-Sync-Wort (11111111 111xxxxx) und sendet von dort Daten an den Codec. Der Codec verfügt nicht immer über die Informationen, die er aufgrund fehlender Bitspeicherdaten in diesem Moment dekodieren muss. Es kann entweder ein wenig Störgeräusch spielen oder still bleiben, bis es genug Informationen hat. Beide Verhaltensweisen existieren in freier Wildbahn.

Schließlich ist das dritte Problem, dass eine normale MP3-Datei/Stream keine Timestamp-Daten enthält. Die Suche in einer Datei ohne Decodierung bis zum gewünschten Suchpunkt ist nur ein Rätselraten. Für die Effizienz, was Spieler oft tun werden, ist "Nadel fallen" in den Stream durch Raten, wo sie beginnen sollten. Wenn der Player weiß, dass Sie einen CBR-Stream mit 320 kbit/s haben und weiß, wie groß die Dateigröße ist, kann er schätzen, wie lange die Datei in der Zeit ist, und einfach gleichmäßig teilen, um den Byte-Offset der gewünschten Suchzeit zu erhalten. Wie Sie sich vorstellen können, ist dies selbst bei CBR ungenau. Bei VBR verwenden einige Spieler den Durchschnitt der Bitrate, die sie bisher gesehen haben. Andere werden das Suchen überhaupt nicht erlauben. Andere schauen auf den ersten Frame, nehmen CBR an und behandeln die gesamte Datei so, als ob sie die gleiche Bitrate wie der erste Frame hätte. (Spielen Sie irgendwann eine VBR-Datei ab und beobachten Sie, wie sich der Endzeitstempel in den ersten Sekunden der Datei ändert. Das liegt daran, dass der Player rät, wie groß die Länge ist.)

Verwandte Themen