Unverständliche Anzeigen zu Bitrate und Länge!

Deutsch / German Allgemein
1

Support oder Bug? Bei wem?

Das Problem ist so oder ähnlich auch anderen Forum-Mitgliedern ( z.B. M.A.X, Stevest und d_headshot) nicht ganz neu.
In Abhängigkeit von der Encodierungsmethode werden bei mir in Mp3tag (v2.41a), Winamp (v5.541) und iTunes (v8.00) Werte bei Bitrate und Länge angezeigt, die "jenseits von Gut und Böse" sind. Im Unterschied dazu sind die angezeigten Werte im WinXP-Explorer immer vernünftig, unbhängig von der Encodierungsmethode.
Wer hilft hier weiter?

Im Detail:
Habe einen gegrabbten Wavefile, hier "test.wav" genannt, für den der Win-Explorer folgende Eigenschaften anzeigt:
Größe=85 MB, Bitrate=1411 kBit/s, Abtastgröße=16 Bit, Kanäle 2(Stereo), Abtastrate=44 kHz, Audioformat=PCM. In WaveLab 6.10 hat dieser Audiofile eine Länge von 08 min und 27 sec.

Dieser Audiofile wird mit zwei unterschiedlichen Methoden encodiert nach MP3 mit VBR:

  1. Methode: Direkt mit Lame_3.97 in der Win-Eingabeaufforderung per "lame --preset fast standard test.wav test_lame.mp3", so dass der Ergebnisfile "test_lame.mp3" heißt.
    (Ursprünglich wurden von mir ca. 10000 Wavfiles mit dieser Methode encodiert!)

  2. Methode: Indirekt in WaveLab mit der in WaveLab eingebauten Lame-Encodierung mit Parameter VBR, wobei hier der Ergebnisfile "test_wavelab.mp3" genannt wird. Die "lame_enc.dll" hat hier den Stand 03.10.2006. Lame-Version und genauere Lame-Parameter werden von WaveLab aber nicht angezeigt.
    (Diese zweite Encodierungsmethode wurde bei weiteren 2000 Wavefiles genutzt, weil sie sich als etwas bequemer in der Handhabung erwies.)

Egebnisanzeige in Win-Explorer / Dateieigenschaften:
bei "test_lame.mp3": Größe(MB): 11, Bitrate(kbps): 192, Länge/Dauer(hh:mm:ss): 00:08:25,
bei "test_wavelab.mp3": Größe(MB): 15,3, Bitrate(kbps): 224, Länge/Dauer(hh:mm:ss): 00:09:37.
Alle Werte bleiben trotz bzw. wegen unterschiedlicher Parameter-Nutzung in vernünftigem Rahmen.

Ergebnisanzeige in Mp3tag, Winamp und iTunes:
bei "test_lame.mp3": Größe(MB): 11, Bitrate(kbps): 183, Länge/Dauer(mm:ss): 08:25 (in Mp3tag), 8:26 (in iTunes), 8:25 (in Winamp),
bei "test_wavelab.mp3": Größe(MB): 15,3, Bitrate(kbps): 32, Länge/Dauer(hh:mm:ss): 01:07:24 (in Mp3tag und iTunes), 67:05 (in Winamp).
Auch hier zeigt die erste Zeile akzeptable Werte.
In der zweiten Zeile sind die Angaben zu Bitrate und Länge aber nicht mehr nachvollziehbar. Insbesondere die Längenangabe von 01:07:24 (in Mp3tag und iTunes) bzw. 67:05 (in Winamp) hat mit der Ausgangslänge des Audiofiles von ca. 8 min nichts mehr zu tun!

Kann mir gut vorstellen, dass die Ursache für dieses "Phänomen" nicht bei Mp3tag liegen muss und liegt. Allerdings wird das störende Ergebnis für den "normalen Endnutzer" erst mit der Anzeige in diesem Programm sichtbar. Sicher ist ein solches Ergebnis aber auch bei weiterer Nutzung in Mp3tag "störend" wirksam!
Wer da an welcher Stelle was falsch macht oder Regeln nicht richtig berücksichtigt, ist für mich nicht im Detail nachvollziehbar. Merkwürdigerweise ist dieses "Phänomen" im Win-Explorer nicht sichtbar!

Die Ergebnisse sind reproduzierbar. Das Beispiel ist kein Einzelfall und dadurch auffällig geworden, dass in meiner Klassik-Sammlung verhältnismäßig wenig mp3-Files mit Längenangaben von mehr als einer Stunde vorkommen.
Würde ungern alle 12000 Wavefiles noch einmal nach der 1.Methode encodieren!!

Vielleicht kann hier das Mp3tag-Support-Team oder das Forum weiterhelfen oder kennt zur Adressierung des Problems einen kundigen Ansprechpartner.
Die Beispiel-Files stehen auf Wunsch zur Verfügung.

Über ein weiterführendes Feedback würde ich mich freuen!
rolf

2

Du solltest mit foobar2000 http://www.foobar2000.org/foobar2000_0.9.5.6.exe im Trackcontextmenu diese Optionen ausprobieren: "Utils/Fix ... Header" und "Utils/Rebuild ... Stream", und die Werte für die Spieldauer danach noch einmal kontrollieren.

DD.20081006.1226.CEST

3

MP3s mit VBR sind so eine »Sache für sich«: Exakte Länge und »echte« durchschnittliche Bitrate können eigentlich nur ermittelt werde, wenn man sich alle Frames »anschaut«. Das würde natürlich zu lange dauern, also haben die Leute bei Xing den sog. »VBR Header« erfunden: Da steht sowas zum schnellen Auslesen drin. Wie es generiert und aktuell gehalten wird, ist ein anderes Problem – diese »VBR Header« sind nicht in jeder Datei vorhanden oder oft auch defekt (wie DetlevD korrekterweise vermutet).

Zudem zeigen verschiedene Player auch verschieden an: Die Sekunden werden mal auf-, mal abgerundet, die Bitrate wird aus dem ersten Frame ermittelt oder die aus dem Header benutzt … Es gibt viele Möglichkeiten, »Mist« anzuzeigen.

Als ersten Schritt für eine »bessere Zukunft« würde ich mir ein paar bekannte Beispiel-Files in ein Verzeichnis kopieren, wo Länge und zu erwartende Bitrate bekannt sind.

Dann zuerst einmal den aktuellen externen Lame installieren und mit dem mit »--vbr-new« testen (ist bei neueren Versionen Standardeinstellung). Wenn Du unbedingt in Wavelab mit der LAME-DLL arbeiten möchtest, solltest auch einmal versuchen, dem die aktuelle DLL »unterzuschieben«.

Es kann sein, dass damit die Probleme schon gelöst sind.

Wenn nicht, kannst Du Dich natürlich als nächstes auf eine »Diagnose-Tour« begeben: Manchmal sind es so Sachen wie ein falsches »Emphasis«-Bit im Header (bspw. CCITJ.17 oder Unknown statt None), eine Datei, die versehentlich als MPEG 1 Layer II oder MPEG 2.5 Layer I oder als MPEG 1 Layer III aber mit mp3PRO codiert sind, usw. Meistens ist aber tatsächlich »nur« der VBR Header (oder der Player!) fehlerhaft. (Einen defekten VBR Header kann man ohne Neu-Encoden des Dateiinhalts reparieren bzw. durch einen neuen ersetzen.)

Gute Tools für sowas sind z.B. der 3delite MP3 Stream Editor (Warnung: Der schreibt ohne Rückfrage non-standard Tags wie SEFC,SEBR,SESC!), oder zum »schnellen VBR Header Fixen« der mp3DirectCut. Nicht zu vergessen natürlich der gute alte foobar2000.

4

Hallo Rolf,

ich weiß nicht ob's dasselbe Problem ist - aber Stichwort Klassik und aberwitzige Werte erinnern mich an den vemeintlichen Bug, den ich anfangs hatte. Der "Fehler" war, daß MP3TAG längere Dateinamen zuläßt als Microsoft, und einige meiner Titel waren schlicht zu lang.

Viele Grüße,
pewe

5

Danke für die schnelle konstruktive Reaktion!

Habe foobar2000 bisher nie benutzt. Deswegen hat der vorgeschlagene Test etwas länger gedauert!
Zur Vorgehensweise:
Habe aus dem fehlerhaften Kandidaten "test_wavelab.mp3" ein "test_wavelab_foobar_fix.mp3" und ein "test_wavelab_foobar_rebuild.mp3" per Kopie erstellt,
um für die Anwendung der Optionen "Utils/Fix ... Header" bzw. "Utils/Rebuild ... Stream" jeweils inhaltlich gleiche, aber verschieden benannte Ausgangsfiles zur Verügung zu haben.

Zum Ergebnis:

  1. In "test_wavelab_foobar_rebuild.mp3" ändert sich bei Anwendung von "Utils/Rebuild ... Stream" in der foobar-Anzeige nichts.
    Auch in Mp3tag, iTunes und Winamp werden die alten fehlerhaften Werte (s.o.) angezeigt!
    (Diese Option empfiehlt sich wohl weniger im vorliegenden Fall!)

  2. In "test_wavelab_foobar_fix.mp3" ändert sich bei Anwendung von "Utils/Fix ... Header" die Anzeige in foobar wie folgt:
    Aus Spieldauer =1:07:24 wird Spieldauer=8:26, und aus Bitrate=32 wird Bitrate=255.
    DIese Werte werden in Mp3tag und iTunes genauso angezeigt.
    (Diese Option müsste dann wohl auf alle 12000 mp3-Files angewandt, wenn man nicht mehr genau weiß, welcher Wavefile mit WaveLab encodiert wurde.)
    Soweit prima!
    A b e r: In Winamp erscheint beim korrigierten File jetzt Spieldauer=33:32 (statt ursprünglich 67:16) und Bitrate=64 (statt ursprünglich 32),
    d.h. "etwas besser und in die richtige Richtung gehend", aber immer noch falsch!
    Hilft hier foobar mit anderen Funktionen weiter? Oder ist da wohl eher Winamp am Zuge?

Kann ich da mit einem weiteren Tipp rechnen? Aus dem Mp3tag-Team oder von einem kundigen Forumsmitglied?
Würde mich freuen!
rolf