# Einführung Tag TRDA / TRDC - Aufnahmedatum
**URL:** https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605
**Category:** Vorschläge
**Created:** [March 6, 2022, 4:56pm UTC](https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605 "2022-03-06T16:56:44Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@schnitt](https://community.mp3tag.de/u/schnitt)
#### Post date: [March 6, 2022, 4:56pm UTC](https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605/1 "2022-03-06T16:56:44Z")
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](https://docs.mp3tag.de/mapping/?de) war es ebenfalls nicht aufgelistet.
Bei meiner Recherche ([id3v2.4.0-changes - ID3.org](https://id3.org/id3v2.4.0-changes?highlight=%28TRDA%29)) 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](https://id3.org) nicht rauslesen ... ob TRDA ein STRING,DATE oder whatever Datentyp ist ...
das bietet Wavelab bei den MP3 Tags an ...
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [March 6, 2022, 5:46pm UTC](https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605/2 "2022-03-06T17:46:44Z")
> [@schnitt](#):
>
> \*in Wavelab / Steiberg gibt es das "TAG" TRDA Aufnahmedatum bei ID3 v2.... im mp3tag v12 konnte ich dieses Feld nicht finden. bzw. in [Mp3tag Hilfe - Tag-Felder](https://docs.mp3tag.de/mapping/?de) war es ebenfalls nicht aufgelistet.
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?
> [@schnitt](#):
>
> ob TRDA ein STRING,DATE oder whatever Datentyp ist
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.
---
### Author:  [@schnitt](https://community.mp3tag.de/u/schnitt)
#### Post date: [March 6, 2022, 8:12pm UTC](https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605/3 "2022-03-06T20:12:03Z")
> [@LyricsLover](#):
>
> 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?
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ß
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 7, 2022, 12:54pm UTC](https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605/4 "2022-03-07T12:54:23Z")
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.
---
### Author:  [@schnitt](https://community.mp3tag.de/u/schnitt)
#### Post date: [March 7, 2022, 3:30pm UTC](https://community.mp3tag.de/t/einfuhrung-tag-trda-trdc-aufnahmedatum/56605/5 "2022-03-07T15:30:42Z")
> [@Florian](#):
>
> 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).
`TRDA` ID3v2.3 Frame ("Recording dates") lt. ID3
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**
> [@Florian](#):
>
> 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.
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_
> [@Florian](#):
>
> 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.
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