Mp3FileUtils

[Gausi]

MP3FileUtils, v0.6


Diese Unit liest aus einer MP3-Datei alle (?) gängigen Informationen aus. Wie bei vielen anderen auch wird der ID3v1-Tag gelesen, fast alle Teile des ID3v2-Tags und diverse Informationen über die Datei ansich, wie z.B. Bitrate und Spieldauer.

Download:

• Mp3FileUtils - Quellcode inkl. der Demoprogramme. Zip-Archiv, ca. 555kb
• Demos. - Komplilierte Demo-Programme zum Ausprobieren. Zip-Archiv, ca. 1.9mb
• Zum Thema Unsynchronisation: "Das Gewitterrätsel - Reloaded" (das war mal eine Aufwärmfrage bei einem Gewinnspiel in der Entwickler-Ecke) (Version 1, Version 2) - Wo war das Gewitter? (Tip: beide Varianten mit dem VLC abspielen und am Scrollbalken spielen )

Änderungen in 0.6:

• Methoden SetRating und SetPersonalPlayCounter zusammengefasst zu SetRatingAndCounter. Der Code in den eigenen Anwendungen muss da ggf. angepasst werden
• Unterstützung von "Private Frames"
• Erkennung des VBRI-Header
• ein paar neue Genres in der Genre-Liste für ID3v1
• neue Methoden Get/SetUserText, GetAllUsertextFrames
• ID3v2Tag.ReadfromStream schneller: Tag wird zuerst komplett geladen, aus dem Memorystream dann die Einzelframes
• Bugfix: Korrektes Lesen von UTF8-kodierten Textframes mit Delphi 2009
• Bugfix: ExtendedHeader-Größe wurde falsch interpretiert
• Bugfix: User-definierte Textframes (TXXX) haben eine andere Struktur als normale Textframes
• Bugfix: Typ-Gemisch bei GetFrameLength behoben

Folgendes leisten die in dieser Unit implementierten Klassen:

1. TID3v1Tag:
   • Lesen und Schreiben des ID3v1-Tags
   • Unterscheidung von v1- und v1.1-Tags
2. TMpegInfo:
   • Lesen/Berechnen der MPEG-Informationen eines mp3-Files - z.B. Bitrate, Channelmode, Samplerate, vbr/cbr, Dauer
   • Schnelles Ermitteln der Daten: Auch bei vbr wird die Spieldauer (fast) immer korrekt ermittelt, ohne die ganze Datei lesen zu müssen
3. TID3v2Tag:
   • Lesen und Schreiben des ID3v2-Tags
   • Unterstützung aller existierenden Versionen: v2.2, v2.3 und v2.4
   • Unterstützung der Standard-Frames wie Titel, Artist, Album
   • Unterstützung einiger weiterer Text-Frames wie orig. Artist, Composer, Mediatype, Encoder
   • Lesen und schreiben von Lyrics, Bildern, Bewertungen, URLs
   • Lesen und schreiben beliebiger Daten
   • Unterstützung von Unsynchronisation, GroupIDs und Datalength-Bytes
   • Unterstützung von Unicode
   • Unbekannte Frames (~ Informationsfelder) im Tag bleiben erhalten

Für Details verweise ich auf die beiliegende Dokumentation und die verschiedenen Demoprojekte.

Evtl. benötigte Zusatzkomponenten/Units:
Nur für Delphi 2007 oder früher. Verwendung kann in der Datei Config.inc geändert werden.

• TntWare Delphi Unicode Controls
  Download unter: http://www.tntware.com/delphicontrols/unicode/

Für Fehlermeldungen oder Codeoptimierungen bin ich jederzeit offen - hier im Thread, per PN oder per Mail.

Edit: Text an die neue Version angepasst.

[DelTurbo]

Eventuell hilft es...
bei id3v2Tag.WriteToFile(Edit1.Text); kommt er mir MP3ERR_Cache zurück.

[Gausi]

Hm, kannst du da mal durchsteppen, weswegen er diesen Fehler zurückgibt? Der Fehler tritt generell auf, wenn das Cachen der Audiodaten fehlschlägt. Da der ID3v2tag am Anfang der Datei steht, muss der ggf. vergrößert werden, wenn mehr Daten gespeichert werden sollen, und auch das häufig vorhandene Padding nicht ausreicht. Dann wird zuerst der Audiodaten-teil in eine temporäre Datei kopiert. Der ID3ERR_Cache-Fehler wird ausgelöst, wenn der FileStream für die tmp-Datei nicht erzeugt werden konnte (also FileStream.Create fehlschlägt oder eine Exception auslöst), oder wenn die Daten nicht komplett kopiert wurden.

Ich hab das hier grade mal mit D7 Personal durchprobiert, hier das wird anstandslos gespeichert.

Die JPEG-Exception kommt im Debugger übrigens, weil die Demo dort unsauber programmiert ist. Da wird mit dem DatenStream, den GetPicture liefert, direkt ein JPEG.LoadFromStream durchgeführt. Ohne Kontrolle, ob da überhaupt was drin steckt. Der fehler wird ohne Debugger einfach durch einen (fast) leeren except-Block ignoriert.

[DelTurbo]

Jop, ich war schon am Tracen. Warum das so ist, wie es ist.... frag mich bitte nicht. Vielleicht hast du eine erklärung.

In der Mp3Utils.Pas Zeile 1890 willst du vom Stream ende, 128 Bytes zurück. Und genau da scheppert es. Ich habe das wie folgt geändert und nun geht es.

Alt:
Stream.Seek(-128, soFromEnd);

Neu:
Stream.Seek(Stream.Size-128, soFromBeginning);

Irgendwie gehört das wieder zu den sachen die ich nicht kapiere. Vielleicht hast du ja eine erklärung. Mir fällt dazu nix ein

Trotzdem vielen dank für deine mühe.

Edit: Mit der DelphiVersion mit der ich arbeite kann es eigentlich nix zu haben. Ich habe es auf 3 Rechnern Probiert.

Edit2:
Ich habe mir das mal in Assembler angesehen. Es ist auf beiden Rechnern (D7,D2009) gleich.
004806EE 66B90200 mov cx,$0002
004806F2 BA80FFFFFF mov edx,$ffffff80
004806F7 8B45EC mov eax,[ebp-$14]
004806FA 8B30 mov esi,[eax]
004806FC FF5614 call dword ptr [esi+$14]

In cx steh das Kommando. Bei uns 2 für soFromEnd. In edx steht $ffffff80, also 128 zurück. eax wird der Pointer sein. Ich weiss wirklich nicht warum das nicht klappt. Auch der call zeigt richtig in TStream.Seek.

Beide Rechner laufen unter Windows XP mit SP3.

[DelTurbo]

Rückmeldung:
Ich habe grade mal aus neugierde ein "sauberes" Windows XP-SP3 genommen, Delphi 7 installiert und deine Demo übersetzt. Läuft einwandfrei.

Was ich auf meinem PC, Laptop und in der Virtuellen installiert habe, das es nicht geht weiss ich leider nicht. Ich müsste nun nach und nach alles nachinstallieren um zu sehen wer da mist baut. Bei sowas kann man natürlich lange suchen....

Vielen dank nochmal und netten Gruss

[juergen]

Hallo Gausi,

zuerst einmal meinen Respekt für deine Arbeit zu diesem Projekt und dem Bereitstellen als offenen Code!
Als einfacher Hobbyprogrammierer konnte ich einiges aus deinem Projekt lernen.

Ich habe jetzt das Problem, dass anscheinend bei einer variablen Bitrate > 256 kbps der ausgelesene Wert der Bitrate aus den MPEG-Informationen falsch ist.
Oft wird nur ein ca. ein 10tel der echten Bitrate angezeigt.
Mir ist das aufgefallen, weil anscheinend Amazon die Bitrate seiner MP3-Lieder erhöht hat.
In diversen Playern wird die richtige Bitrate angezeigt.

Hast du hier eine Idee woher das kommen kann?

Im Rahmen meiner Möglichkeiten stehe ich natürlich gern für Nachfragen, Tests oder dergeleichen zur Verfügung.

Ps.: ich bin mir nicht ganz sicher, meine aber, dass das früher mal richtig angezeigt wurde.

[Gausi]

Hm. Ich habe bisher nur einmal ein Album bei Amazon gekauft, und das hatte konstant 256kbps. Von daher wieder meine Standard-Bitte: Schick mir mal ein oder zwei dieser Dateien, damit ich da mal durchsteppen kann, was da schiefläuft.

Adresse ist "mail ÄTT gausi PUNKT de"

[juergen]

Email mit einer Beispiel-Mp3-Datei ist unterwegs...
Musik ist natürlich Geschmacksache.

Hatte gerade festgestellt dass auch die Liedlänge um Faktor 9 zu lang angezeigt wird.

[juergen]

Hallo Gausi,

es tut mir wirklich leid!
Der Fehler lag bei mir!

Ich hatte gerade in deinen Demos nachgeschaut und da waren die Anzeigen richtig. Also musste es bei mir liegen.

Im Zuge von "Aufräumaktionen" in meinem Code vor ca. 4 Wochen hatte ich dabei an 2 Stellen die Reihenfolge vertauscht gehabt.

Delphi-Quellcode:

    Id3v2Tag.ReadFromStream(stream);  // <= das hatte ich direkt vor "MpegInfo.LoadFromStream(stream)" stehen und deswegen war bei mir der Fehler...
    // an das Ende des Tags springen
    if not Id3v2Tag.exists then
      stream.Seek(0, sobeginning)
    else stream.Seek(Id3v2Tag.size, soFromBeginning);

    MpegInfo.LoadFromStream(stream);
    stream.Free;

Bitte sieh mir meine nicht vollständige Überprüfung meines Codes nach.
Danke!

Ich wünsche allen ein schönes Wochenende!

[Gausi]

Danke für die Datei. Bei mir wird alles richtig angezeigt, aber ich kann die falsche Anzeige reproduzieren und kann bestätigen, dass das vorher richtig angezeigt wurde. Der Fehler liegt nämlich nur zum Teil bei dir.

Problem ist hier tatsächlich das Auslesen des ID3-Tags. Ich habe da in der letzten Version beim Einlesen des Tags etwas geändert - anstatt jeden Frame des ID3-Tags einzeln aus dem orignal-Filestream einzulesen, wird erst der ganze Tag in einen Memorystream kopiert, und aus diesem Stream dann die Frames gelesen. Ich verspreche mir davon schnelleres Lesen bei Laufwerken im Netzwerk.

Problem ist, dass ich nach dem Lesen des Headers "Tag.Size"-Bytes in den Memorystream kopiere, aber den Header ja schon gelesen habe. Daher kopiere ich 10 Bytes zu viel, bin im Orignal-FileStream 10 Bytes zu weit hinten, und verpasse den Beginn des XING-Headers, in dem Infos über die variable Bitrate enthalten sind. Und dann wird angenommen, dass die ersten AudioFrames (Stille, also geringe Bitrate) als passend für die Datei genommen werden. Und da die Länge aus der Bitrate und Dateigröße berechnet wird, wär das dann auch geklärt.

Abhilfe für das Problem hast du ja schon selbst gefunden.

[MW97]

Hallo gausi,

Ich finde deine Units echt toll, aber ich habe ein Problem mit deiner MP3FileUtils.
Ich habe den Code den du im Delphi-Treff im Tutorial geschrieben hast so umgeschrieben, dass ich ohne die Klasse TAudioFile auskomme und nur mit den Dateinamen arbeite. Das funktioniert auch alles sehr gut.
Aber wenn ich mit meinen Programm die Titelinformationen von vielen Dateien aktualisiere(Sie werden in Stringlisten gespeichert), steigt der Speicherverbracuh sehr stakt an. Die StringListen enthalten von Programmstart an schon die Titelinfos und werden beim Start nur aktualisiert.

Ich habe schon allesmögliche mit try finally und Free probiert, aber der Speicherverbracuh steigt von 2 auf 182 MB. (In den Stringlisten speichere ich nur Titel, Interpret und Spiellänge).
Kannst du mir da vielleicht weiterhelfen?
Schon mal Danke im Vorraus.

MW97