Print

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

[jaynyc]

Am looking at the meta tags in my AAC and M4A files... I don't see replaygain tags.  Is this intentional?  I thought MC wrote replaygain tags to AAC and M4A files as well as FLAC, WAV, ALAC, MP3 during Auto-Import.

[ferday]

Have the files been analyzed previously?  Are you sure auto import is analyzing the, during import?

Yes it does write to AAC and m4a

[jaynyc]

Hmm, I'm confused by something then.  I buy a track from iTunes.   Then copy and import to MC20.  Upon import, it auto scans.   This is what it looks like

in the shell dbpoweramp ID3 tag viewer mode.

Then, I drag the track into Foobar.


Foobar does not recognize any ReplayGain tag for this track, because there are no actual ReplayGain tags.  If I then scan the track with Foobar, then the track shows the tags


What am I doing wrong with JRiver, or what is JRiver not doing?

Thanks

[jaynyc]

bump

[blgentry]

I'm not very educated on ReplayGain.  The concept is easy to understand.  I think I get how JRiver's MC uses it to normalize volume on playback.  The main thing I don't know is what tags are used by what players to indicate ReplayGain.  From your files and my experience with JRiver, it seems obvious that MC uses "Volume Level (Replay Gain)".

Then looking at the file you processed in Foobar, I see a tag with the exact same value (out to 2 significant digits) called "replaygain_track_gain".  To me this seems like a player difference.  If you wanted to, I'm pretty darned sure you could add "replaygain_track_gain" as a field in JRiver's library.  Then you could set that field equal to JRiver's "Volume Level (Replay Gain)".  As long as you have "write tags on change" set in the options, that new field should then be written to your AAC (and other) files.

But I really should have asked at the beginning:  What are you trying to accomplish?  Is it just playback in Foobar?  Or something else?

Brian.

[jaynyc]

<snip>

But I really should have asked at the beginning:  What are you trying to accomplish?  Is it just playback in Foobar?  Or something else?

Brian.

Hi Brian
I am looking to have flexibility of volume adjusted playback across multiple players, including portable players like Sansa Clip etc..  That's why I am puzzled, JRiver does all this awesome work to scan and tag, but why not *also* tag the universally accepted replaygain tags as well?

[glynor]

why not *also* tag the universally accepted replaygain tags as well?

Who says the one foobar uses is universally accepted?  Source? Is there an official, documented spec somewhere that MC isn't following?

[6233638]

Is there an official, documented spec somewhere that MC isn't following?

Metadata	Key	Value format
Track replay gain	REPLAYGAIN_TRACK_GAIN	[-]a.bb dB
Peak track amplitude	REPLAYGAIN_TRACK_PEAK	c.dddddd
Album replay gain	REPLAYGAIN_ALBUM_GAIN	[-]a.bb dB
Peak album amplitude	REPLAYGAIN_ALBUM_PEAK	c.dddddd

MC doesn't write SoundCheck/iTunNORM tags either, which is equally frustrating.

[glynor]

That's not any kind of officially accepted ID3 spec, it is a proposal suggested by the people at Hydrogen Audio.  It is a well-thought-out spec, certainly, and the guy even thanked Matt in the Acknowledgements section, but... I don't know much about it other than that some people think it is a good idea.

Is it widely supported by many players other than foobar?

If so, I'd say that MC should be changed to use it, assuming there isn't a technical reason it does not.  Perhaps it just doesn't write these tags correctly for files in MP4 containers? My guess is that MC's support of this stuff pre-dates that suggested spec by a fair margin, and perhaps they didn't know to wrap back around and fix it (or last they looked, it hadn't gotten much traction in other players).

But, I'm no expert. Perhaps Matt can comment.

[6233638]

Is it widely supported by many players other than foobar?

Anything which uses ReplayGain, other than Media Center, reads/writes tags in those formats.
I think MC will even read tags in that format, it just seems to write tags in its own format? See below

[glynor]

Anything which uses ReplayGain, other than Media Center, reads/writes tags in those formats.
I think MC will even read tags in that format, it just seems to write tags in its own format?

Okay. Then +1 they should fix it if there's not some technical limitation that prevents it from working right.

[6233638]

Just did a quick test there and this issue seems contained to AAC/M4A files.
It is writing the correct tags to FLAC/WAV. (note: MC only writes track tags, not album ones)
 
No Soundcheck/iTunNORM tags are written however.
 
 
Somewhat related, iTunes' AAC encoder is comically slow compared to conversions in MC.

[glynor]

Just did a quick test there and this issue seems contained to AAC/M4A files.

I wondered if that was the case.

Perhaps there is some reason? Maybe these tags break playback in some dumb application (some old version of iTunes or something)?  Or, perhaps more likely, it was just an oversight.

[jaynyc]

so I'm overall glad you guys don't think I'm crazy.  6233638 and Brian-- thank you for confirming.

Now curious to learn if JRiver thinks this is a "problem worth solving" or if this is all by design.

[Hendrik]

I'll give this a look tomorrow. We should always try to write standard compliant tags as good as we can.

[Hendrik]

This will be fixed in an upcoming build. The replaygain writing was a bit confused, so I made it smarter and cleaned it up a bit, so in the future M4A files will write this metadata.

[6233638]

Great!

[flight16]

Hooray!  Might be a dumb question, but do the Mac and Linux versions of MC get this change, too?  Do they share any code?

[blgentry]

Hooray!  Might be a dumb question, but do the Mac and Linux versions of MC get this change, too?  Do they share any code?

I would actually like to know a little bit more about JRiver's development coding system with respect to Mac and Linux.  What little I *do* know, I find fascinating.  Here's what I understand about it so far:

Several years ago, JRiver abstracted out all graphics (and maybe sound?) library calls and built their own library of graphics routines.  Presumably these call low level Windows library functions to build windows, menus, etc.  When they ported MC to Mac and Linux, they wrote a new low level interface between the JRiver graphics and windowing code, and the native graphics code of the target platform.  So, in essence, all of the higher level stuff is *completely* untouched.  Only the very low level graphics (and again maybe sound?) system calls are different.

This means that almost every change that's made to the Windows version of MC is automatically propagated to the Mac and Linux versions.  Or at least it *can* be.  I'm not sure how they manage it internally.  I guess, if they are really progressive, there's really one master code repository for all versions, and they just write platform specific code as necessary, probably with some sort of #include statement that detects the target platform.  So windows specific stuff gets compiled on Windows, and Mac specific stuff gets included and compiled on Mac.

I'm guessing at a lot of details, but know the are using a much more centralized code base than most cross platform software.  It's really VERY cool and interesting.  I'd love to hear more about it.

Brian.