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.

[Gausi]

Threadsicher sollte das sein, wenn man unterschiedliche Objekte in unterschiedlichen Threads erzeugt. Allerdings muss man ggf. mit Bitmap-Routinen aufpassen, wenn man die Set/GetPicture-Methoden benutzt.

Ob 700 parallele Threads sinnvoll sind, steht aber noch auf einem ganz anderem Blatt. Da ist die CPU doch nur noch mit hin- und herwechseln beschäftigt.

[juergen]

Hallo Gausi,

mir fehlt momentan noch die Disk-Nummer bzw. CD-Nummer als MP3-Tag um Dateien anhand verschiedener MP3-Tag's umzubenennen.
Eine vorhandene Eigenschaft in deinen tollen Mp3FileUtils konnte ich nicht finden. In deiner Doku auf Seite 10 steht unter "Weitere Text-Informationen" etwas von weiteren Properties, welche über ID's gelesen oder gesetzt werden können. Ich weiß aber gar nicht ob ich da überhaupt richtig bin.
Siehst du eine Möglichkeit über deine Mp3FileUtils an die Disk-Nummer bzw. CD-Nummer ran zu kommen`?

Vielen Dank schon mal vorab!

[ereetzer]

Hallo,
das sollte der Text-Frame ID "IDv2_PARTOFASET" sein, meine ich?

Bsp.
GetText(IDv2_PARTOFASET)

gruß
ereetzer

[Gausi]

Jup, IDv2_PARTOFASET sollte passen. Wenn das für Dateinamen benutzt werden soll, muss man ggf. aufpassen, ob da einfach nur die Nummer drin steckt, oder etwas wie "1/2" (ist afaik die Regel)

[juergen]

ich kam erst jetzt zum Lesen...
Vielen Dank für die Hilfestellung und den Hinweis bezügl. der Schreibweise!

[BlueStarHH]

Hi,

tolles Projekt. Danke! Ich habe allerdings einen Fehler gefunden: Bei mehreren MP3-Dateien fehlt bei diversen Infos (Title, Artist) immer der erste Buchstabe. WinAmp und WindowsMediaPlayer zeigen die Tag-Infos richtig an. Unter http://www.file-upload.net/download-...certo.mp3.html eine Beispieldatei (Mozart, unterliegt nicht mehr dem Copyright. ACHTUNG: Download der MP3 Datei nur über den Button, wie er hier im Anhang abgebildet ist. Nicht dass jemand auf die Banner bei file-upload.net klickt und Mist runterlädt.) In dieser MP3 Datei ergibt

FTitle := Id3v2Tag.GetText(IDv2_TITEL);

"orn concerto" obwohl im Tag "horn concerto" steht. Das am Anfang h fehlt. Was muss ich machen, damit auch der erste Buchstabe mitkommt? Danke!

[juergen]

@BlueStarHH,

ich weiß jetzt nicht genau ob du "nur" auf den Umstand des evtl. fehlerhaften Auslesens von bestimmten Frame-ID's hinweisen möchtest oder ob du eine Lösung für dein Problem suchst. Bei Verfügbarkeit von Tags würde ich eher den "nativen" Tag verwenden und nicht über die Frame-ID gehen:
FTitle := Id3v2Tag.Title

Damit hatte ich noch keine Probleme. Evtl. sind hier auch die Post #48 und #49 interessant.

Edit: laut Bugfix ist mit Version 0.6 "Typ-Gemisch bei GetFrameLength" behoben. Welche Version nutzt du?

[Gausi]

Zitat von BlueStarHH:

Was muss ich machen, damit auch der erste Buchstabe mitkommt? Danke!

3 Möglichkeiten:

1. Auf ein Update von MP3fileUtils warten
2. Vernünftige MP3s runterladen und nicht so einen Quatsch (keine Wertung der Musik, die Tags sind nicht valide)
3. Einen vernünftigen Grabber/Encoder nutzen, der standard-konforme Tags erzeugt.

Fehlerdetails: Der Tag in dem File enthält Unicode. Im ID3-Tag wird dazu vor der eigentlichen Text-Info ein Byte für die Kodierung benutzt.

Problem: Im ID3v2.3-Tag (hier vorhanden) gibt es nur "0" (für Ansi) und "1" (für Unicode). Nach ID3-Spezifikation gilt bei ID3v2.3:

Zitat:

Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order

In der Datei wird "1" verwendet, also Unicode. Aber: das BOM fehlt. D.h. die ersten 2 Bytes (= der erste Buchstabe) werden als BOM interpretiert und somit verschluckt.

Abhilfe wäre, eine Heuristik einzuführen, d.h. wenn die ersten beiden Bytes weder FF FE noch FE FF sind, die korrekte Byteorder raten.

Insofern: Danke für die Datei und die Fehlermeldung. Ich schau mal, was ich da ändern kann.

@juergen: Kann man machen, ändert aber nichts. Der getter für den Titel ruft GetText(IDv2_TITEL) auf.

[BlueStarHH]

Hallo Gausi,

danke für die Aufklärung. Die Tags alle nachträglich zu ändern wird nicht möglich sein. Daher würde ich es sehr gut finden, wenn Du eine Heuristik einbauen würdest. Ich habe jetzt noch andere Programm getestet wie z.B. http://www.mp3tag.de Auch die zeigen alle die Tags richtig an. Warum ein auf Mp3FileUtils basierendes Delphi-Programm es dann nicht macht, ist den Endanwendern nur schwer zu vermitteln. Deswegen warte ich gespannte auf ein Mp3FileUtils-Update. Ich bekomme eine Heuristik leider nicht selbst hin, sonst würde ich helfen.

[Gausi]

Ich hänge hier mal eine korrigierte Version der betreffenden Unit an. Ich habe es mir leicht gemacht, und die Unit so angepasst, dass die hier genannten Files korrekt eingelesen werden, d.h. wenn das BOM fehlt, obwohl es laut Flag eigentlich da sein sollte, dann wird die Datei so eingelesen, als wäre es richtig, dass es nicht da ist. D.h. als UTF-16BE.
Eine Heuristik, welche Byteorder (BE / LE) wahrscheinlicher ist, habe ich nicht eingeführt - halte ich auch für Overkill. Die Unit gibt es jetzt seit einigen Jahren, mein Player nutzt die auch. Ich bekomme durchaus regelmäßig Mails wegen dem - aber bisher noch nie, dass das erste Zeichen in den Infos fehlt.

Edit: Anhang entfernt, da fehlerhaft. Korrektur kommt bald