AudioGenie Forum
September 08, 2010, 05:01:38 *
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
News: Neue Version 2.0.1.3 der AudioGenie DLL verfügbar!
 
Seiten: [1]
  Drucken  
Autor Thema: Datumswerte in AudioGenie3  (Gelesen 503 mal)
wolkenschieber
Newbie
*
Beiträge: 28


Profil anzeigen
« am: Februar 17, 2010, 07:28:38 »

Hallo Stefan,

habe folgendes Problem mit neuer DLL. Bei folgenden Feldern bekomme ich falsche Werte zurück geliefert:

- TDAT
- TDRC
- TDOR

Ich schreibe Datumswerte rein und bekomme nach anschließendem auslesen nur einen leeren String zurück. Die Tag-Version ist auf v2.4 gesetzt. Die Werte für die Felder TDRL, TDEN und TDTG werden einwandfrei gespeichert und wieder gelesen. Ich benutze die Routinen ID3V2GetTextFrame und ID3V2SetTextFrame zum bearbeiten. Schaue ich mir die Datei mit MP3Tag an werden die erwähnten Frames mehrfach angezeigt, sooft ich eben gespeichert habe.

Viele Grüße
Werner
Gespeichert
Stefan
Administrator
Sr. Member
*****
Beiträge: 425



Profil anzeigen WWW
« Antworten #1 am: Februar 17, 2010, 07:47:44 »

Hallo,

TDAT wurde in id3v2.4 ersetzt durch TDRC
Zitat
TDAT - Date
    This frame is replaced by the TDRC frame, 'Recording time'
    [F:4.2.5].
AudioGenie sollte das automatisch konvertieren, aber da muss ein Bug sein, wenn die Felder mehrfach vorkommen. Das soll nicht so sein.

Werde ich mal nachschauen, danke für den Hinweis.

Stefan
Gespeichert

wolkenschieber
Newbie
*
Beiträge: 28


Profil anzeigen
« Antworten #2 am: Februar 18, 2010, 08:45:26 »

Hab mal darüber nachgedacht. AG3 findet die Frames nicht, gibt einen leeren String zurück und speichert sie jedesmal neu. Versuch mal in der Richtung zu suchen.(Nur so'ne Idee).
Gruß
Werner
Gespeichert
Stefan
Administrator
Sr. Member
*****
Beiträge: 425



Profil anzeigen WWW
« Antworten #3 am: März 01, 2010, 11:37:22 »

Also ich habe das nun mal nachvollzogen.
Es ist so, dass die DLL die Frames alle im Speicher gehalten werden, und zwar in der Reihenfolge der Erstellung.
im Beispiel zuerst der TDAT und dann der TDRC. Beim Speichern wird nun ausgewertet, welche id3 Version und welches Encoding verwendet werden soll.
Da id3v2.4 ausgewählt ist, erkennt AG, dass der TDAT Frame durch TDRC ersetzt werden muss und macht das auch brav.
Dann kommt der nächste Frame und speichert ihn auch ab, leider ist das auch ein TDRC Frame. Normalerweise dürfte er den dann nicht speichern.
Das ist gar nicht so leicht zu handeln, momentan habe ich ehrlich gesagt noch keine Idee wie ich daam besten verfahren soll.
Das kann ja auch in umgekehrter Richtung passieren, also die Konvertierung von id3v2.4 zu id3v2.3.

Soll ich dann den ersten Frame speichern und alle nachfolgenden doppelten überlesen oder den ersten überschreiben oder...

Momentan etwas ratlos.

Stefan
Gespeichert

wolkenschieber
Newbie
*
Beiträge: 28


Profil anzeigen
« Antworten #4 am: März 06, 2010, 09:48:39 »

Habe die Sache mal mit der neuesten DLL (v20002) getestet.Ich glaube da sind zwei Probleme. Das Verhalten ist jetzt anders.
Wenn ich TDRC speichere kommt im Tag gar nichts mehr an (der an die DLL übergebene String wird nicht gespeichert). Bei TDRL, TDTG und TDEN funktioniert es. TDOR und TDAT werden mehrfach gespeichert. Wenn ich mit MP3Tag alle TDOR-Frames bis auf einen gültigen lösche, liest die DLL den Wert nicht bzw. gibt einen leeren String zurück.

Ich hoffe du kannst das nachvollziehen. Wenn du irgend etwas brauchst melde dich (Beispieldateien oder so).

Werner
Gespeichert
Stefan
Administrator
Sr. Member
*****
Beiträge: 425



Profil anzeigen WWW
« Antworten #5 am: März 06, 2010, 12:32:09 »

Also ehrlich gesagt habe ich noch garnichts diesbezüglich geändert, da ich mir noch im unklaren bin, wie ich in solchen Fällen verfahren soll.

Konkret an deinem Beispiel:
- TDAT angelegt
- TDRC angelegt
- TDOR angelegt

Nun in id3v2.4 speichern. In diesem Fall wird TDAT durch TDRC ersetzt ( lt. id3v2.4 Spezifikation)
Ergebnis:
- TDRC (altes TDAT)
- TDRC
- TDOR

Was schlägst du vor wie verfahren werden soll ?
Gespeichert

wolkenschieber
Newbie
*
Beiträge: 28


Profil anzeigen
« Antworten #6 am: März 07, 2010, 08:03:20 »

Ich würde ganz pragmatisch ran gehen.
Wenn ein Frame in der Spezifikation 2.4 nicht definiert ist ignoriere ihn einfach, also nicht umsetzen oder speichern. Einen vorhandenen (falschen) Tag löschen. Ich gehe davon aus, dass du umgekehrt einen 2.4-Frame auch nicht im 2.3-Format speicherst. Ein Umsetzen von Werten würde ich der Anwendung überlassen. Keep it simple.

Nicht vergessen das Problem mit dem mehrfach speichern zu lösen  Zwinkernd

Grüße
Werner
Gespeichert
Stefan
Administrator
Sr. Member
*****
Beiträge: 425



Profil anzeigen WWW
« Antworten #7 am: März 07, 2010, 11:07:54 »

Zitat
Wenn ein Frame in der Spezifikation 2.4 nicht definiert ist ignoriere ihn einfach
Aber er ist ja definiert, es steht drin:
Code:
TDAT - Date  This frame is replaced by the TDRC frame
TIME - Time  This frame is replaced by the TDRC frame

Andererseits müsste sich der Anwender darum kümmern, ob und wie umgesetzt wird.
Das wollte ich ihm eigentlich abnehmen, aber da sehe ich momentan keine Chance dazu.
Denn alle TDAT,TIME,TRDA und TYER Frames werden sonst zu TDRC; was soll denn da gescheites drin stehen.

Hast Recht, ich ignoriere diese Frames einfach beim Speichern und schreibe ne Warnung in die Log-Datei.
Dann habe ich auch das Problem mit den doppelten Frames nicht mehr.

Stefan
Gespeichert

Seiten: [1]
  Drucken  
 
Gehe zu:  

UseBB Port by Gaia Modified & Upgraded by Croco Powered by SMF 1.1.11 | SMF © 2006, Simple Machines LLC