Full dates don't sync well on some files.

CambionnCambionn Member
in Bugs

Continuation of the discussion in New Look!: https://community.asti.ga/discussion/comment/2034#Comment_2034

I think I found the issue, or at least a direction of where it goes wrong. While editing files I noticed something. It seems like all mp3 files revert to year-only tags while all flac files work perfectly. It seems somewhere in the syncing process, mp3 files their tag get altered.

I remembered a read something about mp3 files and ID3 DATE vs YEAR fields so I looked it back up and found this thread https://community.mp3tag.de/t/date-vs-year/9819.

It seems the DATE tag was discontinued since ID3v2.4 (which used UTF-8). Currently I'm tagging everything with ID3v2.3 UTF-16 tags as ID3v2.4 mentions not to be supported everywhere. Although YEAR should allow the full date, perhaps it's somewhere here where the issue appears?

Is there anything in Astiga's syncing algorithm that could explain this behaviour on mp3 files (especially while not happening in flac files)? Be it in the ID3 version, character encoding, or the use of DATE instead of YEAR etc.

Comments

  • gravelldgravelld Administrator

    We use getID3() to read the metadata of music files - https://www.getid3.org/ . We don't treat FLAC/MP3 differently, however the library might.

    Another thing to note is that, in our code and following the reading of the tag using the library above, if YEAR is specified, DATE is ignored. Could this be relevant?

  • CambionnCambionn Member

    I'm guessing the library might then. Their link to ID3v2 tags format doesn't work (404), and their last update is over a year old so I started to wonder if it was still maintained. But their github has been updated about 2 weeks ago, so I guess they just don't keep too much track of the website.

    Year isn't set in any of my files, so that if statement shouldn't be applied (the if-statement seems well to prevent the issue in the mp3tag tread I linked tho).

    I tried to test replacing the DATE tag with a YEAR tag, but after that there is no date at all anymore 😬. I do hope converting to another format or editing by hand in Astiga's metadata editor isn't the only solution for mp3 files.

  • gravelldgravelld Administrator

    I'll have to look into exactly what the library does, then, in the next week.

  • gravelldgravelld Administrator
    edited October 2022

    I've just tested this with the library. I'm assuming ID3v2.3 here. Here are my results for different settings of different field.

    TYER      TDAT        getID3 reports...      Astiga derives...
                      YEAR      DATE
2001                  2001                   2001
2001      02-01       2001      02-01        2001
          2001-02-01            2001-02-01   2001-02-01
2001      0201        2001      0201         2001

    With the tagging tools I used I wasn't actually able to see TYER to the full YYYY-MM-DD string - they all accepted the string, but then wrote TDAT as well as TYER. I'm interested if you were able to do this and if the TYER was actually updated to YYYY-MM-DD. Send me a file to info@ if you like.

    Note that the ID3v2.3 spec says:

    TDAT

    The 'Date' frame is a numeric string in the DDMM format containing the date for the recording. This field is always four characters long.

    So this all means that you might only be able to faithfully represent the full date if you can be sure that TYER is not being written.

    Post edited by gravelld on
  • CambionnCambionn Member

    I've send you a file together with a the info I see about it in Picard.

  • gravelldgravelld Administrator

    Thanks!

  • gravelldgravelld Administrator
    edited October 2022

    I received your file and checked it. TDAT is "0605" and TYER is "2003". When I run it through Astiga we just get a YEAR of 2003. So basically it's pretty difficult to set a full year with Astiga right now unless you only use TDAT which is a breakage of the ID3 spec.

    Note that the reason we accept DATE is that other tagging schemas may have a field name that maps to DATE in GetID3.

  • CambionnCambionn Member
    https://community.asti.ga/discussion/comment/2059#Comment_2059

    I see. I'm still curious as to why this only happens to MP3 files tho. When using ID3 tags in FLAC it seems to go well.

    What would be the best way to circumvent this for now?

    Are you planning to work on a way to catch this during sync? Perhaps an if-statement on TDAT being filled with 4 chars/ints (depending what it sets too) while TDAT & TYER are also both set, then combine to create full date in YYYY-MM-DD format? In theory that would solve the issue with MP3 files without breaking other inputs like the FLAC seems to return (unless people set the year in both YEAR and DATE tags, but that I would discourage as that creates both double tags (no SSOT) and is also wrong usage).

    So something like:

    if (TDAT.length = 4 && TYER.isSet && TDAT.isSet)
then {
    #combine to YYYY-MM-DD
}

    But I don't know how difficult that would be inside Astiga's code.

    Or do you recommend changing the DATE tags to TDAT on MP3 files? And in which case, how would I go about that? Would it work to just make a new tag called TDAT?

  • gravelldgravelld Administrator

    Send me an example FLAC file and I'll look into that. Are you sure you're using ID3 inside FLAC though? That's pretty unusual - normally Vorbis comments are used.

    Yeah, we should try to read the full data in, if it's available.

    I do not recommend changing the TDAT fields - that would be against the spec, and it might break other software.

  • CambionnCambionn Member

    I'm not 100% sure to be fair. I have Picard set up with settings for ID3 tags and use tags I know exist from ID3, but I never double checked if they are actually saved as such or if they change it underwater. It was a bit searching as I don't compress my FLAC files, but I found some that are less than 25MB. I'll send you one. What intro tracks aren't good for haha.

    Glad to hear you're going to look into supporting this.

  • gravelldgravelld Administrator

    The FLAC you sent contains a Vorbis comment tag, not an ID3 tag. Only DATE is set to 2000-12-24. That's why we read it correctly in Astiga - there's no YEAR so DATE is used.

    It's common that tag editors abstract the complexity of different tagging schemas and just "do the right thing" (until they don't).

    Vorbis comments don't have field IDs/names like TDAT or TYER , they just use simple name/value pairs and "DATE" is the commonly accepted name for release date... although most software probably also supports "YEAR" too.

  • CambionnCambionn Member
    edited October 2022

    I see, interesting. I knew a bit about digital audio itself (and so I do know that uncompressed FLACs are relatively useless over compressed ones, but I got endless 5G internet and seeing those high bit-rates make me happy 😅), but the tagging part I never knew that much about. Ah well, I guess for now that means I just gotta wait for until you can read the full data in. Guess it gives me some more time to go over all the leftover files I still need to update lol.

    until they don't

    Completely off-topic, but you made me laugh, so thank you. This feeling is the true pain of every "smart" software. It's why I quit git interfaces and went back to terminal for that 🥲. Especially when people used different git GUI's and IDE implementations that all wanted to be "smart" in a slightly different way (which broke stuff), and I always got the blame wrongly even if it made no sense just because I was on Linux and "Linux is scary, unknown, and difficult so that must be the problem" (which I guess is the pain of Linux developers working with others who only know and understand Windows 🥲). At least no one could claim my command did anything else than that exact command because Linux, and I could be sure I wouldn't be the one breaking stuff (unless I actually do do something stupid myself).

  • gravelldgravelld Administrator

    Yeah, I love a command line myself...

Sign In or Register to comment.