R14: Month & day lost when encoding mp3 from FLAC

[tewill]

I just upgraded from R13.5, and noticed that with R14, when encoding mp3 from FLAC, month and day is not preserved in the "year" tag. That is, in the FLAC file the tag value is "YYYY MM DD" yet when encoded to mp3 the tag value is just "YYYY". I found this while encoding to mp3 - not ripping to mp3 - but regardless, for the record, I do have "Force no date on year" unchecked in CD Ripper.

I see an older thread discussing whether only the "YYYY" value should be allowed in the mp3 "year" tag, but I've been using the full "YYYY MM DD" value in mp3s for some time now, and haven't seen any issues in the players I use, i.e. winamp, iTunes.

R13.5 didn't work this way - the full date value was preserved when encoding to mp3 - is this a bug in R14, or is there some new setting I'm missing that's causing this behavior? Ideally I'd prefer it to behave as it did in R13.5, but if the new truncated date is by design, I'd then prefer for there to be a setting that would enable one to choose whether to preserve the entire date value. Thanks!

[Spoon]

Re: R14: Month & day lost when encoding mp3 from FLAC

Technically we were wrong on the YYYY MM DD and it could cause problems for certain players.

[tewill]

Re: R14: Month & day lost when encoding mp3 from FLAC

I understand you were previously technically incorrect per the ID3v2.3 standard, but it appears there is de facto support for more than four characters in the year tag by major applications, including winamp, iTunes, and mp3tag. I'm also inferring that when you say "certain players," you also believe the lack of de facto support was more the exception than the rule. And, from what I can tell, in ID3v2.4 not only will month and day be supported, but also hours, minutes, and seconds, if so desired.

Regardless, beyond this only potentially affecting a minority of applications, it would be much easier for someone preferring the truncated YYYY to remove the extra characters than it would be for someone to add the MM and DD after encoding. For example, in R14 I imagine they could use your new Rule based Tag Manipulation or just Force no date on year when they rip; they could conceivably also use other applications to automatically remove all but the first four characters of the year tag for all their mp3s. For someone preferring the longer format, however, they would most likely have to add the extra characters by hand, which could be a pain when transcoding a large number of albums in a batch.

But, if this is the new normal, I would prefer for there to be a setting where one could choose to maintain the behavior in R13.5. Otherwise, can you provide a workaround for this new functionality? As it is right now, I'm essentially unable to transcode more than a few albums at a time to mp3, which was one of the reasons I bought dMC in the first place. Thanks!

[Spoon]

Re: R14: Month & day lost when encoding mp3 from FLAC

noted

[tewill]

Re: R14: Month & day lost when encoding mp3 from FLAC

Ok, thanks. I'm assuming then that the only workaround is to use R13.5 or earlier?

[tewill]

Re: R14: Month & day lost when encoding mp3 from FLAC

In case anyone is interested, you can keep the full "YYYY MM DD" data from being lost in your mp3s by using the "ID Tag Processing" DSP to map the "Year" tag to a new tag (like "Release Date") when transcoding/encoding. I know that might seem obvious, but I was unsure when in the process of encoding mp3s with R14 the truncation of the "Year" tag occurred (i.e. whether it happened before the "ID Tag Processing" DSP ran). But, FYI it does work.

[Spoon]

Re: R14: Month & day lost when encoding mp3 from FLAC

R14.1 restores this, it is now an option.