Einführung Tag TRDA / TRDC - Aufnahmedatum

Hallo,

*in Wavelab / Steiberg gibt es das "TAG" TRDA Aufnahmedatum bei ID3 v2.... im mp3tag v12 konnte ich dieses Feld nicht finden. bzw. in Tag Field Mappings – Mp3tag Documentation war es ebenfalls nicht aufgelistet.

Bei meiner Recherche (id3v2.4.0-changes - ID3.org) konnte ich rauslesen das in ID3 v2.4 dieses Feld nicht mehr verwendet werden.. soll grmpf. Aber hierzu stelle ich eine Frage / Diskussion ins Board

kann man die folgenden Felder in mp3Tag zur Verfügung stellen ?
a) TRDA "Recording Dates"
*b) TRDC "Recording TIme" * (naja eigentlich wohl eher nicht da lt. Hilfe-Überblick lediglich ID3v1, ID3v2 ... unterstütz wird. und kein ID3v3 bzw ID3v4).

leider konnte ich bei https://id3.org nicht rauslesen ... ob TRDA ein STRING,DATE oder whatever Datentyp ist ...

das bietet Wavelab bei den MP3 Tags an ...

Verstehe ich Dich richtig: Wenn Du in Deinem Wavelab einen Wert in TRDA schreibst, dann kannst Du diesen Wert in Mp3tag auch mit ALT + T nirgends finden?

In der Dokumentation zu ID3v2.3 steht dazu nur:

TRDA
The 'Recording dates' frame is a intended to be used as complement to
the "TYER", "TDAT" and "TIME" frames. E.g. "4th-7th June, 12th June"
in combination with the "TYER" frame.

TYER ist immer 4stellig numerisch und enthält das Jahr, also z.B. 2022
TDAT ist ebenfalls 4 stellig und enthält den Tag und den Monat der Aufnahme im Format DDMM
TIME ist ebenfalls 4 stellig und enthält die Aufnahmezeit im Format HHMM

Wenn ich nun die Beispiele für TRDA ansehe wird es sich wohl um einen String handeln.

ja, richtig .... weder in ALT-T ist das was zu sehen ... noch im "Erweiteren Felder" Dialog, wenn man in der Ansicht wo man seine Audio-Dateien angezeigt bekommt SPlaten hinzufügen möchte

Ich frag mich gerade wie das Mapping dieser "Erweiteren Felder" zu ID3.1 bzw ID3.2v1 -> ID3.2vx in mp3tag erfolgt.
Aktuell verstehe ich das so, das alle Felder unter "Erweiteren Felder" die Grundgesamtheit der "Tags" darstellt die man in eine Datei packen kann wie man möchte und sie mit mp3tag auch angezeigt bekommt. Aber das ist was für ein anderes Post
gruß

Das TRDA ID3v2.3 Frame ("Recording dates") wird von Mp3tag momentan leider nicht unterstützt (aber beim Speichern erhalten).

Ich habe mit der sinnvollen Unterstützung dieses Frames etwas Probleme, da das Äquivalent in ID3v2.4 TDRC ("Recording time") schon auf YEAR abgebildet ist (was aber bei ID3v2.3 wiederum TYER ist).

Leider hatten zur Zeit der Einführung von ID3v2.4 die "großen Player" das Feld TDRC schon für den Zweck des Erscheinungsjahres verwendet. Passender wäre dazu ID3v2.4 TDRL ("Release time"), aber diese Chance ist leider vergeben.

Falls ich nun das ID3v2.3 TRDA als z.B. RECORDINGDATE unterstützen sollte, würde beim Speichern in ID3v2.4 dieses Feld als benutzerdefiniertes Text-Feld TXXX RECORDINGDATE gespeichert werden. Das empfinde ich als nicht optimal.
Alternativ könnte ich auch bei ID3v2.4 ein TRDA Frame verwenden, was dann aber über kurz oder lang einen Bug-Report zur Folge hätte da gegen den "Standard" verstoßen wird.

1 Like

TRDA ID3v2.3 Frame ("Recording dates") lt. ID3

grafik

da die "großen Player" lediglich wohl ein YYYY reinschreiben oder auslesen, oder dann buggen wenn dann was anderes drin steht und MP3TAG dem gefolgt ist, ist das für mich natürlich auch OK ... auch wenn die "großen player" da halt Mist gebaut haben... anyway da wird man nicht rütteln können.

mal ganz flach gedacht:

  • MP3TAG schreibt alles in "benutzerdefinierte Felder" (in der Hoffung das für jede Audiodormat und jede Version der Metadaten davon dies auch zulässt

=> somit kann MP3TAG für sich alleine betrachtet alles handeln
- boing -> aber im zusammenspiel mit anderen Anwendungen (ITUNES , Windowsexplorer etc, WINAMP, VLC ..) würde das eine wüste Flut an Ticket auslösen => gestorben

Alternative Implementierungsmöglichkeiten

ja , das würde wohl nur dazu führen das es wieder Rückfragen gibt .. es gibt doch TRDA Recording Dates .. das könnte man doch verwenden .... man dreht sich dann im Kreis, da die BIG Player das ja anderst interpretieren => gestorben

ja sehe ich auch so, irgendwas haltwegs fixes (ID3 = "Standard" sollte man sich erhalten => gestorben

Fazit

In Ermangelung sinnvoller Implementierungsmöglichkeiten -> Einführung TRDA / TRDC zurückgenommen
danke für die Zeit und kümmern

sonstiges

hmm .. mir ist eh schleierhaft wie TDRC sinnvollvoll aus dem Standard heraus verwendet werden soll
folgendes Dilema ist mir bei ID3v2.4 noch aufgefallen ...
kurz: n Informationen sollen über 1 "Feld" abgehandelt werden ... wie gut das eine Information ATOMAR abgelegt werden sollte ... naja NOSQL hat das ja aufgeweicht (aber andere Diskussion).

bei ID3v2.4 sind ja einige felder deprecated und wurden ersetzt durch das Frame TDRC

TDAT - Date
This frame is replaced by the TDRC frame, 'Recording time'
[F:4.2.5].

TIME - Time
This frame is replaced by the TDRC frame, 'Recording time'
[F:4.2.5].

TRDA - Recording dates
This frame is replaced by the TDRC frame, 'Recording time'
[F:4.2.5].

TYER - Year
This frame is replaced by the TDRC frame, 'Recording time'
[F:4.2.5].

da das UI von MP3TAG ja beliebige "Spalten" anbietet und beim speichern, dann nach einem Regelwerk je nach gewählter Variante (ID3v2.4 + ID3v2.3 ... APE etc) dies in die Datei "einsetztet bzw. updated". Sehe ich gerade folgendes Dilema

wenn jemmand TDAT und TIME auf der UI pflegt (mit unterschiedlcihen Werten, dann kann ja ja bei ID3 nur folgendes Mapping passieren:

a) UI_TDAT + UI_TIME = Datei-TDRC oder
b) UI_TIME + UI_DAT = Datei-TDRC

=> aber lösen andere Hersteller diesen Fall auf ( a) oder (b) ... => grmpf ... Tickets an den Hersteller sind da ja vorprogrammiert

aber was ist wenn auf der UI TDAT und TYER gepflegt wird. quasi: 21.5.2021 und 2022 .... UI_TYER ist ja eine Teilmenge von TDAT ..... => das ginge villleicht ja noch (irgendwie) .... aus 21.5.2021 wird 21.5.2022

aber TRDA (Recording dates , sprich mehrzahl) und
TDAT (Date , sprich Einzal)

=> das muß in einem Feld konsolidiert werden ???? so das sich auch alle Verwender von ID3 das aufgelöst bekommen ?

*grmpf und *grübel .... denke das funktioniert generell einfach nicht