# Länge von Mp3s wird leicht falsch angezeigt.
**URL:** https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243
**Category:** Fehlermeldungen
**Created:** [March 20, 2012, 10:32pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243 "2012-03-20T22:32:00Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [March 20, 2012, 10:32pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/1 "2012-03-20T22:32:00Z")
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](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](http://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](http://www.mixesdb.com) erstellt.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 21, 2012, 5:19am UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/2 "2012-03-21T05:19:36Z")
> [@pone](#):
>
> 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? ...
> die Länge wird scheinbar überall anders angezeigt ...
> 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 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!](https://community.mp3tag.de/t/7296/3)
[Exporting length to CSV file](https://community.mp3tag.de/t/9826/2)
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
---
### Author:  [@Flashin\_39\_95](https://community.mp3tag.de/u/Flashin_39_95)
#### Post date: [March 21, 2012, 10:13pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/3 "2012-03-21T22:13:39Z")
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](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.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 22, 2012, 5:13am UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/4 "2012-03-22T05:13:28Z")
> [@Flashin'95](#):
>
> Wenn der Bug auftritt, sind es immer 4 Sekunden zuviel.
Im Verlgeich zu was? Welche Messmethode zeigt denn die Länge wirklich zuverlässig an?
> [@Flashin'95](#):
>
> Es ist ein klarer Bug, den ich so noch nirgends gesehen habe.
Wie breit ist denn die statistische Basis?
> [@Flashin'95](#):
>
> So wie es ist, ist Mp3tag für mich nicht zuverlässig genug um es im Web weiter zu empfehlen.
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.
---
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [March 22, 2012, 12:55pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/5 "2012-03-22T12:55:43Z")
> [@ohrenkino](#):
>
> Ich verstehe nicht, was die Anzeige eines read-only-Werts mit der Zuverlässigkeit zu tun haben soll.
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](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?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 22, 2012, 1:17pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/6 "2012-03-22T13:17:33Z")
> [@pone](#):
>
> ... Die Tracklänge wird von den den verschiedenen Applikationen dadurch ermittelt ...
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?
---
### Author:  [@dano](https://community.mp3tag.de/u/dano)
#### Post date: [March 22, 2012, 1:34pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/7 "2012-03-22T13:34:13Z")
Ich vermute hier wirklich einen Fehler bei der Berechnung der Dauer von CBR Dateien.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 23, 2012, 7:21am UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/8 "2012-03-23T07:21:14Z")
> [@pone](#):
>
> ... Gibt es Chancen, dass die Methode zu Berechnung der Länge in Mp3tag mittelfristig verbessert wird?
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
---
### Author:  [@dano](https://community.mp3tag.de/u/dano)
#### Post date: [March 23, 2012, 7:07pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/9 "2012-03-23T19:07:56Z")
Länge von Hand berechnen ist genauer:
$div($mul($div($sub(%\_file\_size\_bytes%,%\_tag\_size%),%\_bitrate%),8),1000)
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [March 23, 2012, 8:31pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/10 "2012-03-23T20:31:50Z")
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. 
---
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [March 24, 2012, 3:01pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/11 "2012-03-24T15:01:31Z")
> [@dano](#):
>
> Länge von Hand berechnen ist genauer:
> $div($mul($div($sub(%\_file\_size\_bytes%,%\_tag\_size%),%\_bitrate%),8),1000)
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](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.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 25, 2012, 4:12am UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/12 "2012-03-25T04:12:28Z")
> [@dano](#):
>
> Länge von Hand berechnen ist genauer:
> $div($mul($div($sub(%\_file\_size\_bytes%,%\_tag\_size%),%\_bitrate%),8),1000)
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
---
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [March 25, 2012, 9:27pm UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/13 "2012-03-25T21:27:04Z")
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?
---
### Author:  [@Flashin\_39\_95](https://community.mp3tag.de/u/Flashin_39_95)
#### Post date: [March 31, 2012, 8:20am UTC](https://community.mp3tag.de/t/lange-von-mp3s-wird-leicht-falsch-angezeigt/13243/14 "2012-03-31T08:20:27Z")
Another example: [http://soundcloud.com/clft/marcelus-clft0036/download](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