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:

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:

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:

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:

Zitat von Luckie

Warum die gloable Variabel clsMP3ID3vX?

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

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.

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.

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ß!

Zitat:

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:

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 :mrgreen:)

Zitat:

Zitat von Techcrawler

Zitat:

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:

Zitat von Techcrawler

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.

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:

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 :mrgreen:

[Luckie]

Zitat:

Zitat von Techcrawler

Zitat:

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:

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:

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:

Zitat von Luckie

Warum die gloable Variabel clsMP3ID3vX?

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

Hä? :gruebel: 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:

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:

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:

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:

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:

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:

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:

Zitat von Gausi

Naja. ID3v2Tags sind ja auch nur unwesentlich komplizierter als ID3v1Tags :mrgreen:

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

[Techcrawler]

Zitat:

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:

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:

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:

Zitat von Techcrawler

Zitat:

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:

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? :mrgreen:


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.

[Techcrawler]

Danke nochmal für alle Infos.
Sobald wieder Zeit vorhanden ist, führe ich das ganze weiter.
Bis dahin gehe ich im allgemeinen Arbeitsstreß unter *glugg*

[Muetze1]

Nochwas: Warum liest du keinen Record anstatt eines Buffers? Dann könntest du dir auch die Schleifen sparen können. Siehe Lib in der Signatur.

[OldGrumpy]

Nochmal was zum Thema lesen, schreiben und Filenamen übergeben... Ich hab mehrere Libs in Gebrauch, die einen etwas anderen Ansatz haben: Es gibt ein Objekt namens z.B. TAudioInfo, das Properties wie Interpret (Artist), Songtitel, usw. hat, und Methoden, um diese Infos in ein File zu schreiben bzw. daraus zu lesen. Eine Objektinstanz fest an ein File zu binden... naja, Ansichtssache, mir gefällt obige Idee halt einfach besser :)

BTW, warum wollt ihr Fehler immer über Exceptions "rausreichen"? Schlechte Angewohnheit? Oder "Hamwer schon immer so gemacht"? Im "Windows von heute" haben Exceptions im Vergleich zu eigenem Errorhandling enormen Overhead, Microsoft (man kann von den Jungs halten was man will, aber grossenteils können die schon was) setzt nicht umsonst auf andere Wege. Neuere Methoden (Win32 API, MFC, ATL, usw.) liefern in den allermeisten Fällen ein BOOL zurück anhand dessen man feststellen kann obs einen Fehler gab - und wenns einen gab, dann kann man über GetLastError rausfinden, was passiert ist. Ausnahmen gibts natürlich auch hier, es gibt z.B. CreateFile-Aufrufe (bei den MFC-Klassen zumindest) denen ein Pointer auf ein vorgefertigtes Exception-Objekt mitgegeben wird. Falls dann der Rückgabewert FALSE ist, schaut man halt ins Exception-Objekt rein, um rauszufinden was Sache ist.

Exceptions sollte man sich für die wirklich bösen Showstopper aufsparen, Access Violations zum Beispiel.

Hier gibts nen netten Artikel zu dem Thema...

Zitat:

Depending on your environment, just raising one exception can be from 10-100.000 times as slow as alternatively returning a simple return code from the method.

Ich denke, das sollte man beherzigen. Oder wie seht Ihr das?

[Luckie]

Wegen der Instanz und dem Dateinamen: Deswegen zwei Konstruktoren, da kann es sich jeder aussuchen. Beim Zuweisen der Datei-Property ist eine Exception gerechtfertigt, da ohne Datei das ganz keinen Sinn macht. Die Exception bei GetMp3Info ist geschmackssache.