Codeprüfung/-vorschläge | Thema: MP3, ID-Infos

[Techcrawler]

Hi,
ich habe just for fun mal eine Unit zum extrahieren der ID-Infos aus MP3 Dateien geschrieben und es sieht so aus, als würde diese auch gut funktionieren.
Nun möchte ich gern mal das 'tausend-augen-prinzip' nutzen und euch mal bitten, dass ihr euch den Code mal anseht, ob da evtl. Fehler drin sind oder was ich noch verbessern kann. Das ganze bezieht sich bisher nur auf ID3v1 Tags, die ID3v2´s kommen später mit rein.
Ich danke allen, die sich die Mühe machen, im vorraus.
Der Delphicode ist die komplette .pas Datei.

Delphi-Quellcode:

unit mp3idvx;

interface

uses classes, SysUtils;

type
    TID3v1 = record
        Songtitel: string;
        Kuenstler: string;
        Album: string;
        Erscheinungsjahr: string;
        Kommentar: string;
        Genre: string;
    end;
    TMP3ID3vX = class
        private
        public
            function getID3v1Information(filenameWithPath: string; var ID3v1Infos: TID3v1): integer;
    end;

var
    clsMP3ID3vX: TMP3ID3vX; 

implementation

function TMP3ID3vX.getID3v1Information(filenameWithPath: string; var ID3v1Infos: TID3v1): integer;
var
    fstream: TFileStream;
    buffer: string;
    i: integer;
begin
    // Stream öffnen
    fstream := TFileStream.Create(filenameWithPath,fmOpenRead or fmShareDenyNone);

    // Pufferlänge einstellen
    SetLength(buffer,128);

    // An den Anfang der ID3v1 Informationen gehen
    fstream.Seek(-128,soFromEnd);

    // 128 Bytes in den Puffer laden
    if (fstream.Read(buffer[1],128) < 128) then
    begin
        // Datenmenge reicht nicht für einlesen aus, Fehler
        result                      := -1;
        exit;
    end;

    // Freigeben des FileStreams, da nicht mehr benötigt
    fstream.Free;

    // Songtitel extrahieren
    ID3v1Infos.Songtitel            := '';    
    for i:=4 to 33 do
        ID3v1Infos.Songtitel        := ID3v1Infos.Songtitel+buffer[i];

    // Künstler/Interpret extrahieren
    ID3v1Infos.Kuenstler            := '';
    for i:=34 to 63 do
        ID3v1Infos.Kuenstler        := ID3v1Infos.Kuenstler+buffer[i];

    // Albuminformationen extrahieren
    ID3v1Infos.Album                := '';
    for i:=64 to 93 do
        ID3v1Infos.Album            := ID3v1Infos.Album+buffer[i];

    // Erscheinungsjahr extrahieren
    ID3v1Infos.Erscheinungsjahr     := '';
    for i:=94 to 97 do
        ID3v1Infos.Erscheinungsjahr := ID3v1Infos.Erscheinungsjahr+buffer[i];

    // Kommentar extrahieren
    ID3v1Infos.Kommentar            := '';
    for i:=98 to 127 do
        ID3v1Infos.Kommentar        := ID3v1Infos.Kommentar+buffer[i];

    // Genre extrahieren
    ID3v1Infos.Genre                := buffer[128];

    // Alles okay, Rückgabe
    result                          := 0;
end;

end.

Wer das ganze mal testen möchte, braucht eine Form, einen Button und einen FileDialog (bei mir aus den Jedi Sachen, kann aber auch der Standartdialog sein), 6 Labels und einen Verweis auf die obige Unit.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
    mp3info: TID3v1;
begin
    if JvOpenDialog1.Execute then
    begin
        if (clsMP3ID3vX.getID3v1Information(JvOpenDialog1.FileName,mp3info) >= 0) then
        begin
            Label1.Caption      := 'Songtitel: '+mp3info.Songtitel;
            Label2.Caption      := 'Künstler/Interpret: '+mp3info.Kuenstler;
            Label3.Caption      := 'Album: '+mp3info.Album;
            Label4.Caption      := 'Erscheinungsjahr: '+mp3info.Erscheinungsjahr;
            Label5.Caption      := 'Kommentar: '+mp3info.Kommentar;
            Label6.Caption      := 'Genre: '+mp3info.Genre;
        end
        else begin
            MessageDlg('Es trat ein Fehler auf!', mtError, [mbOK], 0);
        end;
    end;
end;

[Luckie]

Die Kommentare sind alle Überflüssig.

Die Methode getID3v1Information würde ich private machen, das "g" groß schreiben und eine entsprechende read-Property einführen. Später kannst du dann die read-Property noch um eine write-Property erweitern, wenn man dann auch Informationen schreiben kann mit deiner Klasse.

Als Rückgabetyp würde ich Boolean nehmen, wenn du keine weiteren eigenen Fehlercodes definierts.

Warum die gloable Variabel clsMP3ID3vX?

Wie wäre es mit einem Konstruktor, dem du den Dateinamen übergibst?

Ich würde die Daten nicht in einem Record zurückgeben, sondern über Properties.

Und das:

Delphi-Quellcode:

for i:=4 to 33 do
        ID3v1Infos.Songtitel        := ID3v1Infos.Songtitel+buffer[i];

Sieht auch komisch aus. Wenn der Titel kürzer ist, aber das String-Ende Zeichen fehlt, schreibst du Mist in das Feld. Zumindest ein Trim sollte noch folgen. Und könnte man da nicht SetString nehmen oder so?

Delphi-Quellcode:

type
  TMp3Info = class(TObject);
    private
      procedure SetFilename(const Filename: String);
      function GetFilename: String;
      function GetMp3Info: Boolean;
      function GetTitle: String;
      function GetArtist: String;
      // ..
    public
      procedure Create(const Filename: String); override;
      procedure Create; override;
      property Filename: String read GetFilename write SetFilename;
      property Title: String read GetTitle;
      property Artist: String read GetArtist;
      // ...
  end;

So. Zwei Konstruktoren, damit, wenn man meherer Datein abfragen will, nicht immer die Instanz neu anlegen muss. Dafür brauchen wir auch die Property Filename. SetFilename sollte eine Exception auslösen, wenn die Datei nicht existiert. GetMp3Info sollte auch eine Exception auslösen, wenn die ID3 Informationen nicht gelesen werden können und auch noch mal, überprüfen, ob die Datei immer noch da ist und dann eventuell auch eine Exception auslösen. (Kann ja sein, dass sie nicht mehr da ist, weil sie gelöscht, umbenannt wurde oder das Laufwerk nicht mehr verfügbar ist.) Insofern könnte GetMp3Info auch eine Prozedur sein.

Das wäre meine Lösung. Muss nicht die Meinung aller treffen, aber so sieht es für mich sauber und schlüssig aus.

[Techcrawler]

Zitat von Luckie:

Die Kommentare sind alle Überflüssig.

Ich schreibe immer Kommentare in meinen Code, in diesem Beispiel sind die Kommentare sehr gekürzt.
Vor allem für Leute, die meinen Code später mal lesen wollen, erhöht das die Lesbarkeit.
Solange die Kommentare keine Zeitliche verzögerung bedeuten oder das compilierte Programm vergrößern, können die drinbleiben (das ist ja eh ansichtssache des einzelnen Entwicklers).

Zitat von Luckie:

Die Methode getID3v1Information würde ich private machen, das "g" groß schreiben und eine entsprechende read-Property einführen. Später kannst du dann die read-Property noch um eine write-Property erweitern, wenn man dann auch Informationen schreiben kann mit deiner Klasse.

Schreiben würde ich dann als 'setID3v1Information' schreiben, als Übergabe dann wieder Dateiname und MP3Info Record.

Zitat von Luckie:

Als Rückgabetyp würde ich Boolean nehmen, wenn du keine weiteren eigenen Fehlercodes definierts.

Doch, da kommen noch Fehlercodes rein, z.B. wenn das Tag 'TAG' fehlt usw.

Zitat von Luckie:

Warum die gloable Variabel clsMP3ID3vX?

Zum Zugriff auf die Klasse von anderen Klassen (Forms, usw.) aus.

Zitat von Luckie:

Wie wäre es mit einem Konstruktor, dem du den Dateinamen übergibst?

Hatte ich auch mal gedacht, diese Methode ist aber schneller.

Zitat von Luckie:

Ich würde die Daten nicht in einem Record zurückgeben, sondern über Properties.

Könnte man auch, ich finde aber, dass ist Ansichtssache des einzelnen. Evtl. stelle ich beides zur Verfügung.

Zitat von Luckie:

Und das:

Delphi-Quellcode:

for i:=4 to 33 do
        ID3v1Infos.Songtitel        := ID3v1Infos.Songtitel+buffer[i];

Sieht auch komisch aus. Wenn der Titel kürzer ist, aber das String-Ende Zeichen fehlt, schreibst du Mist in das Feld. Zumindest ein Trim sollte noch folgen. Und könnte man da nicht SetString nehmen oder so?

Jo, die for-Schleife ist nur ein Schnellschuß (die unit entstand in 20 min.). Bin an der Stelle für Vorschläge offen.
Laut Spec ist das Feld _genau_ 30 Zeichen groß!

Zitat von Luckie:

Das wäre meine Lösung. Muss nicht die Meinung aller treffen, aber so sieht es für mich sauber und schlüssig aus.

Ich danke in jedem Fall für deine Anregungen und schaue sie mir nochmal genau an. Wie gesagt ist das natürlich immer aus der Sicht des einzelnen Entwicklers; der eine findet es so besser, der andere eben anders.
Aber mich freut es schon mal, dass du keine Fehler 'an-sich' gefunden hast.

[Der_Unwissende]

Hi,
ich denke da gibt es wirklich ein paar Punkte, die du dir noch mal überlegen solltest. Ok, sehe gerade den roten Kasten und möchte die Kritik dort ergänzen.

An sich solltest du wirklich überlegen, ob du hier ein Record verwenden möchtest. Deine TMP3ID3vX ist ja schon mal eine Klasse, da sehe ich dann wenig Sinn nicht komplett auf die OOP zu setzen. Das ganze bringt dir schon mal mindestens den Vorteil, dass du dich weniger um die Speicherverwaltung kümmern musst. Zudem kannst du das var beim übergeben weglassen, denn hier würde aut. eine Referenz übergeben werden.

Was völlig fehlt ist bei dir jegliches Fehlermanagment. Das wurde zwar schon gesagt, aber auffällig ist, dass du hier davon ausgehst, dass du einen gültigen Pfad bekommst. Was aber wenn der nicht mehr gültig ist (jmd. wählt die Datei aus und verschiebt die kurze Zeit später, löscht sie, ...). Da solltest du auf jeden Fall mit einem Ressourcenschutzblock arbeiten und an sich immer dafür sorgen, dass alle erzeugten Ressourcen immer sicher frei gegeben werden.
Ganz schlecht ist auch die Art und Weise, wie du hier mit den Strings arbeitest. Strings sind eine sehr besondere Struktur, du solltest sie immer als eine Klasse mit statischem impliziten Konstruktor betrachten. Anders gesagt, jede Änderung des Strings bring etwas Overhead mit sich, da größerer Speicher alloziert wird, der alte String dort hineinkopiert und um den neuen String erweitert wird. Besser als eine Schleife und ein s + x ist es, wenn du hier einfach copy verwendest und direkt den entsprechenden Bereich in einem Rutsch kopierst.
Dann solltest du auch noch schauen, um welche Version von ID3v1 es sich handelt, wenn ich mich da richtig erinnere, gab es da zwei und die solltest du auch unterscheiden (einmal mit und einmal ohne Genre?).

Zu guter letzt würde ich jetzt noch sagen, dass dein Klassenname TMP3ID3vX gaaaanz schlecht gewählt ist. Erstens solltest du hier nicht einfach nur Großbuchstaben (sehen wir vom x ab) verwenden. Nur der Anfangsbuchstabe eines Wortes, aber auch eines Akronyms, etc. sollte groß geschrieben werden, das macht es viel leichter möglich zu erkennen, worum es sich hier handelt. Der Name TMp3Id3vX wäre aber immernoch schlecht gewählt. vX? Da würde ich jetzt nicht davon ausgehen, dass ich ein TId3v1 bekomme, sondern die Auswahl habe (bei dir noch nicht berücksichtigt, geht aber nicht aus dem Namen hervor).

Gruß Der Unwissende

Zitat von Techcrawler:

Solange die Kommentare keine Zeitliche verzögerung bedeuten oder das compilierte Programm vergrößern, können die drinbleiben (das ist ja eh ansichtssache des einzelnen Entwicklers).

Äh, Kommentare werden immer vom Compiler gelöscht (sonst wären das ja Annotationen )

Zitat von Techcrawler:

Zitat von Luckie:

Warum die gloable Variabel clsMP3ID3vX?

Zum Zugriff auf die Klasse von anderen Klassen (Forms, usw.) aus.

Ganz schlechter Weg! Schau dir mal das Singleton Pattern an, besserer Weg! Oder halt erzeugen wenn man es benutzt und danach wieder frei geben (dann können auch mehrere gleichzeitig arbeiten.

Zitat von Techcrawler:

Zitat von Luckie:

Wie wäre es mit einem Konstruktor, dem du den Dateinamen übergibst?

Hatte ich auch mal gedacht, diese Methode ist aber schneller.

Von wie vielen ms reden wir hier?

[Gausi]

Was auf jeden Fall fehlt: Eine Abfrage, ob der ID3-Tag überhaupt vorhanden ist!

Denn bei Byte 128 vom Ende aus gesehen muss kein ID3v1-Tag beginnen. Er kann da beginnen. Wenn dort keiner zu finden ist, gibt deine Funktion Datenmüll zurück, wahrscheinlich die letzten paar Bytes des (der) letzten MPEG-Frames.

Ein ID3v1Tag fängt mit 'TAG' an.

Weiter wäre Unterstützung des v1.1-Tags schön. Das ist eine kleine Erweiterung: Wenn das 29. Byte des Kommentarfeldes 0 ist, und das 30. ungleich 0, dann enthält dieses letzte Kommentar-Byte die Tracknummer.

Zitat von Techcrawler:

Das ganze bezieht sich bisher nur auf ID3v1 Tags, die ID3v2´s kommen später mit rein.

Naja. ID3v2Tags sind ja auch nur unwesentlich komplizierter als ID3v1Tags

[Luckie]

Zitat von Techcrawler:

Zitat von Luckie:

Die Kommentare sind alle Überflüssig.

Ich schreibe immer Kommentare in meinen Code, in diesem Beispiel sind die Kommentare sehr gekürzt.
Vor allem für Leute, die meinen Code später mal lesen wollen, erhöht das die Lesbarkeit.

In diesme Fall eben nicht. das:

Delphi-Quellcode:

// Songtitel extrahieren
    ID3v1Infos.Songtitel            := '';   
    for i:=4 to 33 do
        ID3v1Infos.Songtitel        := ID3v1Infos.Songtitel+buffer[i];

Muss ich nur kommentieren, wenn in SongTitel nachher die Fläche eines n-Dimensionalen Oktaeders steht anstatt des SongTitels. Das Feld heißt doch schon Songtitel, was soll da anders drinne stehen?

Zitat:

Zitat von Luckie:

Die Methode getID3v1Information würde ich private machen, das "g" groß schreiben und eine entsprechende read-Property einführen. Später kannst du dann die read-Property noch um eine write-Property erweitern, wenn man dann auch Informationen schreiben kann mit deiner Klasse.

Schreiben würde ich dann als 'setID3v1Information' schreiben, als Übergabe dann wieder Dateiname und MP3Info Record.

Nein, das machst du schon über den Konstruktor oder über die property Filename. Der Dateiname hat an dieser Stelle nichts zu suchen, finde ich.

Zitat:

Zitat von Luckie:

Als Rückgabetyp würde ich Boolean nehmen, wenn du keine weiteren eigenen Fehlercodes definierts.

Doch, da kommen noch Fehlercodes rein, z.B. wenn das Tag 'TAG' fehlt usw.

Würde ich auch über Exceptions lösen.

Zitat:

Zitat von Luckie:

Warum die gloable Variabel clsMP3ID3vX?

Zum Zugriff auf die Klasse von anderen Klassen (Forms, usw.) aus.

Hä? Deswegen einen Konstruktor. Was du machst ist gefährlich. Was wenn aus verschiedenen Units darauf zugegriffen wird? Kann sehr leicht zu inkonsistenz der Daten führen.

Zitat:

Zitat von Luckie:

Wie wäre es mit einem Konstruktor, dem du den Dateinamen übergibst?

Hatte ich auch mal gedacht, diese Methode ist aber schneller.

Schneller? Ich glaube kaum, dass du es merkst, wenn es zwei Nanosekunden schneller geht. Der Flaschen hals hier sind die for-Schleifen und nicht das erzeugen einer Instanz mit einem Konstruktor.

Zitat:

Zitat von Luckie:

Ich würde die Daten nicht in einem Record zurückgeben, sondern über Properties.

Könnte man auch, ich finde aber, dass ist Ansichtssache des einzelnen. Evtl. stelle ich beides zur Verfügung.

Finde ich nicht. Mit deiner Methode muss ich immer noch eine extra Variable in meinem Code deklarieren. Mit Properties brauche ich das nicht.

Zitat:

Zitat von Luckie:

Und das:

Delphi-Quellcode:

for i:=4 to 33 do
        ID3v1Infos.Songtitel        := ID3v1Infos.Songtitel+buffer[i];

Sieht auch komisch aus. Wenn der Titel kürzer ist, aber das String-Ende Zeichen fehlt, schreibst du Mist in das Feld. Zumindest ein Trim sollte noch folgen. Und könnte man da nicht SetString nehmen oder so?

Jo, die for-Schleife ist nur ein Schnellschuß (die unit entstand in 20 min.). Bin an der Stelle für Vorschläge offen.
Laut Spec ist das Feld _genau_ 30 Zeichen groß!

Aber nicht jeder Songtitel ist 30 zeichen lang. Was steht in den restlichen Bytes?

Deine Lösung erfordert übrigens keine Klasse. Wozu? besteht doch nur aus einer Funktion. Und so wie du Klassen nutzt, mit einer globalen Variable ist das äußerst schlecht.

Wo wird in deinem Beispiel Code eigentlich die Klasse instanziert? getID3v1Information ist doch keine Klassen-Methode. Nuimm mal die gloable Variable raus und du wirst sehen, dass du erst den Konstruktor aufrufen musst.

[Techcrawler]

Zitat von Gausi:

Was auf jeden Fall fehlt: Eine Abfrage, ob der ID3-Tag überhaupt vorhanden ist!
Denn bei Byte 128 vom Ende aus gesehen muss kein ID3v1-Tag beginnen. Er kann da beginnen. Wenn dort keiner zu finden ist, gibt deine Funktion Datenmüll zurück, wahrscheinlich die letzten paar Bytes des (der) letzten MPEG-Frames.

Stimmt, ist nicht drin, aber berücksichtigt -> kommt noch!

Zitat von Gausi:

Ein ID3v1Tag fängt mit 'TAG' an.

Danke, ist bekannt...die unit ist nur ein Schnellschuß gewesen, werde mir nächstes mal mehr Zeit nehmen...

Zitat von Gausi:

Weiter wäre Unterstützung des v1.1-Tags schön. Das ist eine kleine Erweiterung: Wenn das 29. Byte des Kommentarfeldes 0 ist, und das 30. ungleich 0, dann enthält dieses letzte Kommentar-Byte die Tracknummer.

Rein technisch: Woran erkenne ich, ob es v1.0 oder v1.1 ist?
In der Doku finde ich dazu nichts, auch in einzelnen MP3 ist nichts zu finden, was eine Unterscheidung möglich macht...

Zitat von Gausi:

Naja. ID3v2Tags sind ja auch nur unwesentlich komplizierter als ID3v1Tags

Jo, eben, darum kommen die ja auch später

[Techcrawler]

Zitat von Luckie:

Aber nicht jeder Songtitel ist 30 zeichen lang. Was steht in den restlichen Bytes?

Also, wenn ich in den Editor schaue sehe ich da Platzhalter (Leerzeichen, denke ich, zumindest sind es keine Steuerzeichen).
Bisher habe ich aber nichts dazu in den entsprechenden Specs gefunden, was da reinsoll, wenn nichts da ist. Ich gehe daher davon aus, dass die restlichen Zeichen Leerzeichen sind. In meiner Sammlung habe ich bisher keine Datei gefunden, wo dies nicht so wäre. Wenn aber jemand was findet, immer her damit

Zitat von Luckie:

Deine Lösung erfordert übrigens keine Klasse. Wozu? besteht doch nur aus einer Funktion. Und so wie du Klassen nutzt, mit einer globalen Variable ist das äußerst schlecht.

Okay, dass mit dem globalen Aufruf ist schlecht, gebe ich ja zu...
Zur Klasse: Ja, bisher ist es nur eine Funktion, aber die Klasse soll ja mal alle ID-Tags extrahieren...also kommen da noch weitere Funktionen rein (z.B. getID3v2Info, wenn ich so weitermachen _würde_).

Mir ging es erstmal drum, ob es MP3 Daten mit ID3v1 Daten gibt, die damit nicht oder fehlerhaft gelesen werden würden. Unter dem Entdeckerdrang litt dann auch die Codeschönheit, was aber nun korrigiert wird.
Ich mache das meist so, dass ich ein Gebiet erstmal 'Quick&Dirty' erforsche, dann teste ob es läuft und dann den Code nochmal neu schreibe, mit all den Erfahrungen und Erkentnissen, die ich aus den vorangegangenen Phasen gesammelt haben.

Zitat von Luckie:

Schneller? Ich glaube kaum, dass du es merkst, wenn es zwei Nanosekunden schneller geht. Der Flaschen hals hier sind die for-Schleifen und nicht das erzeugen einer Instanz mit einem Konstruktor.

Es ging mir nicht um die Abarbeitungsgeschwindigkeit, sondern um die Zeit, in der ich die Application fertig habe, um sie zu testen (siehe oben). Quick&Dirty eben, aber es läuft.
Schönheit und Stabilität wird nachgereicht!

[Muetze1]

Zitat von Techcrawler:

Zitat von Gausi:

Weiter wäre Unterstützung des v1.1-Tags schön. Das ist eine kleine Erweiterung: Wenn das 29. Byte des Kommentarfeldes 0 ist, und das 30. ungleich 0, dann enthält dieses letzte Kommentar-Byte die Tracknummer.

Rein technisch: Woran erkenne ich, ob es v1.0 oder v1.1 ist?
In der Doku finde ich dazu nichts, auch in einzelnen MP3 ist nichts zu finden, was eine Unterscheidung möglich macht...

Die Unterscheidung bzw. Erkennung hat Gausi schon geschrieben und du gequotet. Wenn das 29. = #0 und das 30. <> #0 ist. Was ist daran denn nicht klar?

[Gausi]

Zitat von Techcrawler:

Also, wenn ich in den Editor schaue sehe ich da Platzhalter (Leerzeichen, denke ich, zumindest sind es keine Steuerzeichen).
Bisher habe ich aber nichts dazu in den entsprechenden Specs gefunden, was da reinsoll, wenn nichts da ist. Ich gehe daher davon aus, dass die restlichen Zeichen Leerzeichen sind. In meiner Sammlung habe ich bisher keine Datei gefunden, wo dies nicht so wäre. Wenn aber jemand was findet, immer her damit

Normalerweise sollten nicht benötigte Zeichen mit 0 aufgefüllt werden. Manche Tagger füllen das leider auch mit Leerzeichen auf. Prinzipiell sollte gelten: Sobald ein Nullbyte gelesen wird, ist die Tag-Information zuende. Mir sind mal ein paar untergekommen, wo nach einem Nullbyte weitere Zeichen kamen, die aber keinen Sinn machten (irgendwelche Zufallszeichen jenseits des Ascii-Zeichensatzes).

Zitat:

Mir ging es erstmal drum, ob es MP3 Daten mit ID3v1 Daten gibt, die damit nicht oder fehlerhaft gelesen werden würden. Unter dem Entdeckerdrang litt dann auch die Codeschönheit, was aber nun korrigiert wird.

Gibt es, ja. Aber die werden dann auch vom Windows-Mediaplayer falsch angezeigt. Wobei "falsch" nicht ganz richtig ist...wer garantiert dir, dass in dem ID3Tag der "normale" Zeichensatz und nicht ein Multibyte-Zeichensatz wie z.B. Chinesisch verwendet wurde?


Zu den Specs: http://www.id3.org/id3v1.html :

Zitat:

As all artists doesn't have a 30 character name it is said that if there is some bytes left after the information is entered in the field, those bytes should be fille with the binary value 0.

[...]

One who found a way out was Michael Mutschler who made a quite clever improvement on ID3v1. Since all non-filled fields must be padded with zeroed bytes its a good assumption that all ID3v1 readers will stop reading the field when they encounter a zeroed byte. If the second last byte of a field is zeroed and the last one isn't we have an extra byte to fill with information. As the comments field is to short to write anything useful in the ID3v1.1 standard declares that this field should be 28 characters, that the next byte always should be zero and that the last byte before the genre byte should contain which track on the CD this music comes from.