Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nsteele]

For the last several versions at least, when ripping CDs to FLAC files, MC13 is incorrectly formatting the "Year" field in the tag as YYYYMMDD, instead of just YYYY as it should be and as it used to correctly do.  This is screwing up other programs' ability to correctly read these tags, and thus necessitating that I go back and manually edit each of these file tags with another editing program, since the tag editor in MC13 displays this field as YYYY, even though the actual underlying format is YYYYMMDD.  Thanks,

Nick Steele 

[Alex B]

MC11, MC12 and MC13 have this "year" problem. The problem is caused by the FLAC decoder plugin's field mappings. It doesn't show up until the files are used with other applications or devices. The problem has been reported several times, but obviously it has not been high on JRiver's to-do list.

[bob]

Checking into it...

[Alex B]

A suggestion:

Write the year value to the "Date" FLAC tag and MC's complete date value to "JR Date" or similar.

The APE and MP3 taggers use that system. It's possible to tag the month and day values to APE and MP3 files when preferred.

[nsteele]

Interesting.  I've used MC for years without this problem in 11 or 12.  I was however using Oblong's FLAC encoder and decoder previously, so it must be JRiver's plugins that are doing it, since I've just started using them with 13.  I think I'll go back to Oblong's FLAC plug ins until JRiver addresses with their encoder.  Guys, I know it's low on priority, but it would be a quick fix.

Nick Steele

[bob]

Alex, I modified it to write the tags as you suggested.
Anything else w/ flac before we fold it into the build?

[Alex B]

I am quoting myself:

... Since the MC12 beta I have written other tag requests in a memo. I intended test a few related things and rewrite it before posting the list here, but since I have not time to do that here's the list as it is now. The ID3v2 user fields part is implemented now.

ID3v2

Write album gain (would be usable for e.g. Rockbox users, the album peak value is needed for preventing possible clipping when album gain is used):
TXXX replay_gain_album_gain  (add the +6 dB correction)
TXXX replay_gain_album_peak  - when the album gain value is automatically calculated store the highest track peak value

User fields:
Continue reading the old "comment" frames, but write the user and MC's proprietary tags in the TXXX format.
TXXX "name"  must be the actual field name -- not anything like "Media Jukebox: xxx"


FLAC

Fix the date problem. (Now it writes values like 2008/01/01 instead of 2008)

Change the replay gain tag format to follow the FLAC standard. Add the +6 dB correction to the file tags.

APE

Stop using the "Media jukebox" string in front of the tag names. It makes the tags incompatible in both directions.

Replay gain: You could say that the current JRiver way is Matt's standard. However, it would be better to use the more common other style (i.e. replaygain_track_gain etc). Add the +6 dB correction to the file tags.


Ogg Vorbis

Change to be identical with FLAC tagging.
-- except with embedded cover art which does not have an "ogg standard". Continue using text encoding for cover art.


WMA

Does MS recommend adding a creator sepcific identifier in front of the field name? (MC uses JR/) I have seen some other programs doing similar thigns, so maybe the behavior is correct and should not be changed. WMP does not allow user tags so the proprietary name is probably a non-issue if all WMP generated tags can be read.

Change the Replay Gain tags format. It could be made compartible with Winamp and foobar (these appear to be using the replay_gain_track_gain, etc format).


MPC

Stop using the "Media jukebox" string in front of the tag names. It makes the tags incompatible in both directions.

Change the Replay Gain tags format (MPC has always had its own standard).

The replain gain format change with the +6 dB correction is implemented in the ID3v2 tagger (except the album gain part). Check the following threads for details:
http://yabb.jriver.com/interact/index.php?topic=38695.0
http://yabb.jriver.com/interact/index.php?topic=45711.0
http://yabb.jriver.com/interact/index.php?topic=45465.0

[JimH]

6. Fixed: Updated how FLAC tagging writes the date field to be more compatible with other programs.

This fix is now available here:

http://yabb.jriver.com/interact/index.php?topic=49444.0

[pillshovel]

Now my FLAC files don't show any date at all.  All the dates are still there in MP3Tag and dbpoweramp in the correct fields.  Do I need to change something with the mapping in MC13?  I have it all at the default settings right now and mp3's still show the date in MC, but not FLAC.  If I bring up the tag info (all tags) in MC there is no field that has the date but it is there in all other programs (including MC12).

[Alex B]

I think you have found a new bug.

MC writes the Date field now correctly, but it reads the "Date" value only from the new JR_DATE tag. (JR_DATE stores the exact time code that can include the month, day and time values.)

It should read both tags. If there is no JR_DATE tag it should use the year value from the DATE tag.

It is also possible that the the JR_DATE tag is unsynced with the DATE tag. This can happen if the DATE tag (aka year value) has been fixed outside MC. In this case MC should probably ignore the existing JR_DATE value and solely use the DATE value for creating a new internal time code. If the internally used database format allows to override only the year part it could preserve the month, date and time values from the JR_DATE tag when the fixed year is read from the DATE tag (this may not be possible if only the time codes like "39416,4694444444467081" are stored internally).

The tag reader should also provide backwards compatibility so that it would correctly interpret older MC tagged files that have DATE values like 2008/01/01 (the old tagger always saved only "January 1st" dates so that should not be too difficult).

[pillshovel]

Mine are all tagged externally when I rip with dbpoweramp ripper so that would explain it.  I'm hoping to see a fix for this as it creates a pretty big problem for some of my playlists.

Thanks for the response.

[bob]

Actually it looks like it's working with the just the DATE for me. I just tested it again on a file without the JR_DATE.

METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 295
  vendor string: reference libFLAC 1.1.2 20050205
  comments: 12
    comment[0]: DATE=3456
    comment[1]: TOOL NAME=Media Center
    comment[2]: TOOL VERSION=13.0.76
    comment[3]: TITLE=flacyearonly2
    comment[4]: PEAK LEVEL=0.8507999777793884
    comment[5]: BPM=89
    comment[6]: REPLAY GAIN=-8.02881
    comment[7]: INTENSITY=2
    comment[8]: COMMENT=** comment
    comment[9]: CONDUCTOR=foo
    comment[10]: COMPOSER=bar
    comment[11]: COPYRIGHT=1999

And when I look at the DATE tag in MC, the date is 3456 (my whimsical year).

I'm thinking perhaps it's that I missed handling the old MC formatted date in the flac date field. Can you confirm that it works with a standard flac date in the date field?

[Alex B]

Bob, please try the attached file. It does not work for me.

[pillshovel]

Any progress on this yet?  It's absolutely driving me crazy. 

[bob]

Looking at it.

[pillshovel]

Thank you.  I really appreciate it.

[bob]

Interesting,
I was using metaflac (from the flac package) to write the test tags.
Metaflac writes the tags null terminated.
Alex's test file has tags that are not null terminated.

Try the attached .dll (unzip it, copy it over the one in your mc13 plugins directory).
Report back

[Alex B]

The fixed plug-in appears to be working correctly.

The fix doesn't resolve the problem with external updates. JR_DATE has still preference over the separate DATE value, but I guess fixing it would not be easy. If it can't be fixed probably someday someone will ask why the changed year values do not show up in MC. This problem is not limited to the FLAC format.

[bob]

The fixed plug-in appears to be working correctly.

The fix doesn't resolve the problem with external updates. JR_DATE has still preference over the separate DATE value, but I guess fixing it would not be easy. If it can't be fixed probably someday someone will ask why the changed year values do not show up in MC. This problem is not limited to the FLAC format.

I was wary of that same problem so I'm only reading the JR_DATE if it exists and fall back to DATE if it doesn't. When writing, we write both.

I'm adjusting the replay gain. If the version of MC used to tag the file is current, when writing, we'll add 6db to the internal MC value and on reading we'll subtract the read value to get the internal MC value.

If the file is tagged with an older version of MC (or the tag is non-existent)  and we are reading the replay gain we'll report it as it is.

[Alex B]

I just noticed that MC12 can't read a date tag that was created with the fixed MC13 plug-in. Foobar and Winamp can read the same test files without problems.

I don't know if this should be considered as a big problem. I guess that not many users tag FLAC files with MC13 and then import them to MC12. MJ12 should be fixed though.

I'm adjusting the replay gain. If the version of MC used to tag the file is current, when writing, we'll add 6db to the internal MC value and on reading we'll subtract the read value to get the internal MC value.

If the file is tagged with an older version of MC (or the tag is non-existent)  and we are reading the replay gain we'll report it as it is.

Hmm.. are you saying that you are changing the tag names too? -- to REPLAYGAIN_TRACK_PEAK and REPLAYGAIN_TRACK_GAIN . Most, if not all other programs and devices use these names.

One thing you should check is that the decimal separator inside a replay gain tag is always a dot indepedently of what happens to be inside the library field. (This can be either comma or dot depending on the OS settings. The library files may be a mix of both styles.)

[pillshovel]

The fixed plug-in appears to be working correctly.

The fix doesn't resolve the problem with external updates. JR_DATE has still preference over the separate DATE value, but I guess fixing it would not be easy. If it can't be fixed probably someday someone will ask why the changed year values do not show up in MC. This problem is not limited to the FLAC format.

I do all my tagging externally so this is going to be a big issue for me and I just recently bought MC13.  Why not just go back to the old dates that were at least showing up (like in MC12)?  Is there not some way to change the format of the old date to just the year or at least change something in the mapping so that dates modified outside of MC show up.  I have no intention of retagging 18,000 files, if I can help it.

[Alex B]

How often you first write tags with MC and then change the year value outside MC?

If you do that you could also delete the JR_DATE tag. Then MC would read the DATE tag again.

Alternatively you could disable tag writing in the DATE field's options. It does not prevent reading. It would allow you to save all other tags to the files.


Bob,

Could this be fixed by adding a plugin option? Something like:

Read and write precise date and time values. Will use only the year value when disabled. [tickbox]

When disabled it would read and write only the DATE tag.

[pillshovel]

Currently I don't let MC right any tags at all.  I do all my tagging when ripping (outside of MC) and any tag editing gets done in MP3Tag, so currently all my tagging is outside of MC and my dates don't show up on any FLAC's in MC13 right now (they show fine in MC12).  All other formats are fine though.  Does the above .dll fix the reading too even if I'm not writing in MC?  I'm confused.

[bob]

I just noticed that MC12 can't read a date tag that was created with the fixed MC13 plug-in. Foobar and Winamp can read the same test files without problems.

I don't know if this should be considered as a big problem. I guess that not many users tag FLAC files with MC13 and then import them to MC12. MJ12 should be fixed though.

I'd assume that MC12 can't read the standard flac date tag then since that is what I'm supposedly writing (according to metaflac anyway).
I agree on MJ12.

Hmm.. are you saying that you are changing the tag names too? -- to REPLAYGAIN_TRACK_PEAK and REPLAYGAIN_TRACK_GAIN . Most, if not all other programs and devices use these names.

Yes, I guess we'll write those and delete REPLAY GAIN if it exists.

One thing you should check is that the decimal separator inside the file tag is always a dot indepedantly of what happens to be inside the library field. (This can be either comma or dot depending on the OS settings. The values inside the library may be of both styles.)

Will check..

[bob]

Currently I don't let MC right any tags at all.  I do all my tagging when ripping (outside of MC) and any tag editing gets done in MP3Tag, so currently all my tagging is outside of MC and my dates don't show up on any FLAC's in MC13 right now (they show fine in MC12).  All other formats are fine though.  Does the above .dll fix the reading too even if I'm not writing in MC?  I'm confused.

It WILL read the externally generated DATE tag properly (using the .dll above).
It will only WRITE the higher precision JR_DATE tag (and update the standard DATE tag) if you rewrite the tags from within MC.

[pillshovel]

Interesting,
I was using metaflac (from the flac package) to write the test tags.
Metaflac writes the tags null terminated.
Alex's test file has tags that are not null terminated.

Try the attached .dll (unzip it, copy it over the one in your mc13 plugins directory).
Report back

Just tried it and unfortunately the dates still don't show up for me.  To be clear that is while connected to my main library server, so do I have to update it there too before it can read them?

[JimH]

Probably.

[Alex B]

I'd assume that MC12 can't read the standard flac date tag then since that is what I'm supposedly writing (according to metaflac anyway).

In my experience MC12 can read date tags written by other common programs. It just uses to odd "year/01/01" format when it writes tags.

Could you try Mp3tag (for instance) and check how it writes the tag?

[pillshovel]

In my experience MC12 can read date tags written by other common programs. It just uses to odd "year/01/01" format when it writes tags.

Could you try Mp3tag (for instance) and check how it writes the tag.

MC12 never had any issue with reading my tags (I noticed the odd format write and that is why I don't let it write them).   

I just tried the new dll on the main server and still no dates show up unless I use the update library from tags feature.  Auto import (set to update from external changes) doesn't seem to be picking it up like it did in MC12.  Is there something I need to do differently and does updating from tags erase any data that is only in the library (not in the tags)?

[Alex B]

It WILL read the externally generated DATE tag properly (using the .dll above).
It will only WRITE the higher precision JR_DATE tag (and update the standard DATE tag) if you rewrite the tags from within MC.

But it does not read the DATE tag if the JR_DATE tag exists. If someone fixes year values outside MC13 there is no simple way to import the changed values if the JR_DATE tag is also present. This would look like a bug to most users who use only the simple year values.

However, it would be good to preserve the capability to write precise values. For example, someone might want to use them with personal recordings.

[Alex B]

I just tried the new dll on the main server and still no dates show up unless I use the update library from tags feature.  Auto import (set to update from external changes) doesn't seem to be picking it up like it did in MC12.  Is there something I need to do differently and does updating from tags erase any data that is only in the library (not in the tags)?

Auto-Import didn't detect any changes because the file modification times were not changed.

"Update Library (from tags)" updates only the field values that are in the file tags so you can use it safely.

Though I'd recommend creating an new library backup file before doing any big changes to the library. Just in case something unexpected happens.

[pillshovel]

OK, that seemed to work.  Will this update be included in future builds or is it something I need to do manually for any future installs?

[JimH]

It will be in the next build of MC13.

[pillshovel]

Thanks for all the help.  As long as you guys stay this responsive to feedback, I'll buy each future version

[JimH]

Thanks very much, but just so you know, Alex B is "just" an extraordinary user, not part of the staff of JRiver.

[Alexis]

Just to add a feedback voice: after updating to 0.82b, MC13 has stopped seeing the Year tag in all Flac and MP3 files on my machine too. (It did see it before.)
Best to all,
Alexis

[pillshovel]

Just to add a feedback voice: after updating to 0.82b, MC13 has stopped seeing the Year tag in all Flac and MP3 files on my machine too. (It did see it before.)
Best to all,
Alexis

Have you already tried the updated FLAC mentioned above?  That fixed the problem for me.  If you have tried it, be sure to update the library from the tags or they still won't show up.

[Alexis]

Yes, the updated in_flac.dll seems to be fixing the year problem. Great. Thanks! 

[pillshovel]

It seams that this problem is back in 13.0.95 unless you replace the in_Flac with the fixed one in this thread. 

[nsteele]

I agree that the issue is still present.  Still having problem reading MC13.0.95 created FLAC tags with an external hardware device (Escient Fireball).  If I use DB Poweramp to overwrite the YEAR tag for these files to just read "YYYY" it then works fine. Thx,

Nick Steele

[bob]

Should be in the next build