Länge von Mp3s wird leicht falsch angezeigt.


#1

In letzter Zeit ist mir immer wieder aufgefallen, dass die Anzeige der Länge ( %_length% ) in Mp3tag nicht ganz korrekt zu sein scheint. Weiß jemand woran das liegt? Kann mann da was ändern? Wird das in Mp3tag in Zukunft evtl. verbessert?
Ein defekter Mp3-Header ist glaub ich nicht die Ursuche. Diesen in Foobar zu reparieren ergibt keinen Unterschied.

Hier eine Beispieldatei:
http://soundcloud.com/arma17/cassy-nye-2012

die Länge wird scheinbar überall anders angezeigt:

Mp3tag: 1:00:09
mp3DirectCut: 1:00:05.58
Foobar2000: 1:00:05.532 (159 003 946 samples) => gerundete Anzeige 1:00:06
VLC Player: 1:00:05
Winamp: 1:00:05
WMP, in der Playlist: 1:00:07
WMP, Dateieigenschaften: 1:00:06
Windows (Dateieigenschaften): 1:00:06
soundcloud.com stream player: 1:00:07 (hier ist aber nicht die Original Datei im Stream Player, sondern eine 128 kbps Version davon)

Woran liegt es, das scheinbar jede Software die Länge anders interpretiert? Und wie weiß ich jetzt, was die richtige Länge ist?
Auffällig ist, dass Mp3tag am weitesten vom Durchschnittswert weg ist.

Das Problem ist deshalb für mich relevant, weil ich zusammen ein Export Skript für Mp3tag erstellt habe, das aus den Dateien automatisch neue Einträge für http://www.mixesdb.com erstellt.


play length / duration / CBR / VBR
#2

Das Problem mit der unterschiedlichen Anzeige der Abspieldauer je Applikation ist seit vielen Jahren bekannt.
Warum es dazu eine weltweite Vereinbarung nicht gibt, das ist mir echt ein Rätsel.

Siehe auch:
Unverständliche Anzeigen zu Bitrate und Länge!
[X] Exporting length to CSV file

Wenn man sich im Zeitraster von Selunden bewegt, sollte man meiner Meinung nach eine 'angebrochene Sekunde' immer auf die nächste ganze Sekunde aufrunden.
Wenn man eine feinere Zeit Granulation wie z. B. Millisekunden benutzt, verschiebt sich das Problem nur um drei Stellen nach rechts.
Oder muss man dann nicht mehr entscheiden, ob abrunden oder aufrunden auf die nächst liegende Millisekunde?
Aber auch dann würde ich das Aufrunden als die bessere Methode empfehlen.
Wie gesagt, wer mit Tonbändern und Musik-Cassetten gearbeitet hat, der weiß, dass das Aufrunden der Abspieldauer von Musiktiteln immer bestens dazu geeignet war, wirklich alle die Titel auf die laufenden Meter des Bandes zu bekommen, die vollständig darauf passen.

DD.20120321.0720.CET


#3

Wenn der Bug auftritt, sind es immer 4 Sekunden zuviel. Das hat mit Rundungsproblemen und Größeneinheiten nichts zu tun, denke ich. Beispiel-Datei: http://soundcloud.com/arma17/cassy-nye-2012/download

Es ist ein klarer Bug, den ich so noch nirgends gesehen habe.
Wäre schön, wenn er behoben werden könnte. So wie es ist, ist Mp3tag für mich nicht zuverlässig genug um es im Web weiter zu empfehlen.


#4

Im Verlgeich zu was? Welche Messmethode zeigt denn die Länge wirklich zuverlässig an?

Wie breit ist denn die statistische Basis?

Ich verstehe nicht, was die Anzeige eines read-only-Werts mit der Zuverlässigkeit zu tun haben soll.

Oder beziehst du dich auf Version X von MP3tag (siehe dein Profil)? Vielleicht ist die Abweichung ja in der Version besonders schlimm.


#5

Weil hier Mp3tag nicht wie allgemein üblich vornehmlich zum Taggen der Mp3s benutzt werden soll, sondern zum Export der einiger ID Tag Felder und vor allem auch der Technischen Werte %_length"%, %_bitrate% und %_file_size%. Wie gesagt, daraus sollen die Einträge für die Datenbank http://www.mixesdb.com generiert werden.

Um das Problem zusammen zu fassen (wie ich das jetzt versteh):

  • Die Tracklänge wird von den den verschiedenen Applikationen dadurch ermittelt, dass sie die Menge der Sample pro Sample Frequenz berechnen. (So entnehme ich das dem englischen Beitrag, den DetlevD verlinkt hat, was das genau bedeutet ist mir schleierhaft).
  • Für diese Berechnung scheint es verschiedene Methoden zu geben, daher die unterschiedlichen Werte der verschiedenen Player.
  • Mp3tag liegt dabei releativ weit vom Durchschnitt entfernt. Das legt die Vermutung nahe, dass der Wert, den Mp3tag berechnet auch am weitesten vom tatsächlichen Wert entfernt ist.

Die Frage kann wahrscheinlich nur Florian klären (oder jemand mit Einblick in die Methode, wie Mp3tag das berechnet):
Ist meine oben aufgestellte Zusammenfassung korrekt?

und:
Gibt es Chancen, dass die Methode zu Berechnung der Länge in Mp3tag mittelfristig verbessert wird?


#6

Für mich würde das bedeuten, dass ich auf Werte zurückgreife, die fest stehen. Denn wenn andere Anwendungen auch nur Schätzwerte abliefern, dann weiß ich ja nie, welche Länge die korrekte ist und welche Abweichung es momentan im gewählten Kalkulationsmodus gibt.

Also wäre es doch viel redlicher, die Länge der Datei in Bytes, die Kodierungsmethode anzugeben (VBR oder CBR) und für CBR die Bitrate - denn bei VBR ist die Bitrate doch auch nur ein Mittelwert, oder?


#7

Ich vermute hier wirklich einen Fehler bei der Berechnung der Dauer von CBR Dateien.


#8

Nach Prüfung der Beispieldatei (alle Tags entfernt, mit Foobar den Stream und den VBR Header neu geschrieben) vermute ich eine falsche Berechnung in Mp3tag.
Weil es sich hierbei um eine Datei mit Gapless Informationen handelt, rechnet Mp3tag vielleicht falsch?

DD.20120323.0920.CET


#9

Länge von Hand berechnen ist genauer:
$div($mul($div($sub(%_file_size_bytes%,%_tag_size%),%_bitrate%),8),1000)


Länge der MP3-Datei in Millisekunden und Anzahl der Dateien im aktuellen Verzeichnis ermitteln?
TLEN and Song Length
#10

Ein kurzer Vergleich mit der Längen-Angabe aus der AcoustID-Fingerprint-Duration zeigt: Dano hat recht, 100% Übereinstimmung mit der Sekunden-Anzeige aus %ACOUSTID FINGERPRINT DURATION%
Wobei ich jetzt auch keine Abweichung von mehr als 1 Sekunde zur Anzeige mit %_length% entdecken konnte. :huh:


#11

Ich habe den Eindruck, dass die Methode besser funktioniert. Allerdings weiß ich nicht, auf die welches Programm ich mich bei der Anzeige als sichere Referenz verlassen kann.

Ich hab jetzt einen Ordner mit 35 Mp3 DJ Mixen getestet. Das Bild im Link stellt die verschiedenen Längenangaben zusammen.
Die Spalten sind von links nach rechts: WMP, Winamp, Foobar, VLC Player, Mp3tag. Steht aber auch nochmal im Bild
In der "test" Spalte von Mp3tag stehen vor dem Slash die Sekunden nach Danos Formel berechnet, nach dem Slash das ursprüngliche %_length_seconds%.

Vergleichs-Bild:
http://www.mediafire.com/i/?p5skzuj5kcpjaof

In der Formel von Dano werden angebrochenen Sekunden immer abgerundet. Deshalb ist bei vielen Dateien in meiner Screenshot Übersicht eine Sekunde unterschied.
Das könnte mann noch realtive einfach mit einer $mod() Funktion ausbessern.


#12

Ja, diese Formel liefert im Vergleich zu vorher einen etwas besseren Wert, aber eben auch nicht den korrekten Wert, weil hier abgerundet wird durch die Vernachlässigung der Millisekunden wegen der Ganzzahl-Arithmetik.

DD.20120325.0812.CEST


#13

Hier die Formal von Dano mit Auf- und Abrundung:

$add($div($mul($div($sub(%_file_size_bytes%,%_tag_size%),%_bitrate%),8),1000),$ifgreater($mod($mul($div($sub(%_file_size_bytes%,%_tag_size%),%_bitrate%),8),1000),499,1,0))

Und hier mit Aufrundung für alle angebrochenen Sekunden, wie DetelvD es vorschlägt:

$add($div($mul($div($sub(%_file_size_bytes%,%_tag_size%),%_bitrate%),8),1000),$ifgreater($mod($mul($div($sub(%_file_size_bytes%,%_tag_size%),%_bitrate%),8),1000),0,1,0))

Was soll mit dem Rest von $div($sub(%_file_size_bytes%,%_tag_size%),%_bitrate%) geschehen? Sollte da auch gerundet werden, oder sollte mann das irgendwie anders verrechnen?


#14

Another example: http://soundcloud.com/clft/marcelus-clft0036/download is actually 55:49 after decoding to WAV

  • 55:45 in Winamp
  • 55:49 in Mp3tag, SoundCloud, mp3DirectCut