Hi all

[first, apologies for the lengthy post]

I'm using EAC v0.95 beta 4 and REACT v2.0 to create FLACs and M4As. I've updated the version of aacgain.exe that REACT2 uses to v1.7.

The scripting from REACT works fine: I do indeed get playable FLAC and M4A files, however, the replay gain tags that specifically aacgain adds are not being recognised by foobar2000 (v0.9.4.3): the values just don't display in either the Properties dialog or the Edit ReplayGain Info dialog.

In my REACT2 scripts, I'm using neroAacTag v1.0.7.0 to add standard tags and a custom tag. Here is the list-meta output from neroAacTag:


(media-guid is my custom tag)

So, where are the replay gain tags supposedly added by aacgain?

I note in the readme for aacgain it states:


So I used AtomicParsley to view the tags, here's the command and it's output:


It's clear now that all the replay gain tags are being 'prefixed' or have a 'namespace' (whatever the correct term is) of "com.apple.iTunes", and perhaps this is why foobar2000 ain't seeing them.

To make things slightly wierder, I used foobar2000 to scan and add replaygain using "Scan Selection as Single Album", which it now added ok, but look at the tag outputs again:



and



Note the newly appearing tags from neroAacTag, and the reordering and two missing tags from AtomicParsley.

It appears that the inclusion of "replaygain_album_minmax" and "replaygain_track_minmax" mean that foobar2000 skips all the replaygain info.

So, I'd like to know:
1. is the "com.apple.iTunes" necessary? Is this purely for iTunes compatibility?
2. why is my "media-guid" tag prefixed with "com.apple.iTunes" ?
3. can the order of tags be altered to be compatible with foobar2000 ?
4. are the "replaygain_album_minmax" and "replaygain_track_minmax" tags required by iTunes?
5. is this an AACGain issue or a foobar2000 issue? or neither?
6. are there any other options I should try?

Thanks very much for reading!
Roland

I am the author of AACGain, and I can answer some of your questions:

AACgain uses mpeg4ip's mp4v2 library to read and write the metadata. mp4v2 appends the "com.apple.iTunes". There is no way (short of my patching their code) to turn that off.

AACGain and foobar have very different approaches, and it doesn't make much sense to me to mix them.

Foobar analyzes the audio, writes the tags, and uses those tags to control the playback volume.

AACGain's intended use is to modify the track's volume so that the volume playback is at the correct level on non-replaygain-aware players.

So if foobar is your intended player, use foobar to do the gain analysis.

If you want to actually alter your track's volume, then use AACGain to both analyze and apply the gain. At this point, the track's volume will play on foobar at the intended volume (at least within .75dB of it) even though foobar can't read the AACGain tags.

Don't worry about the minmax tags. They are used by AACgain to determine when to issue "wrap" warnings. Those almost never happen.

Hope that helps!

Dave

Hi Dave, thanks for you quick response.

Got it, I understand the difference now: I also spotted during my comparison tests (albeit *after* I posted) that the sample data was different.

What I didn't realise was that MP3Gain and AACGain both apply gain to the actual sample data, rather than relying on the decoder/player to apply gain during replay. That took a bit of digging in the docs to confirm, as it wasn't too clear initially.

Yeah, it wouldn't make sense to mix the two schemes: adding foobar reaplygain tags to an already aacgain'ed file would muck around with the mix, at least within foobar.

Cheers
Roland

Hi, Dave!

I recently submitted a patch to libmp4v2 to be able to set this "owner" string. In the next version of Winamp, I will be using "org.hydrogenaudio.replaygain" as the string for Replay Gain values. I sent a note to Peter Pawlowski about this change, but never heard a reply (but writing the tag in this way won't break foobar2000).

Patch is here:
http://mpeg4ip.cvs.sourceforge.net/mpeg4ip...&sortby=rev

When reading freeform metadata, the implementation is to ignore the "owner" string if you don't specify one yourself. Software using older versions of libmp4v2 will also pick up the values, as it ignores the "owner" string also.

@benski Whats wrong with leaving them as com.apple.itunes? nothing uses tha part? and all program look for it.

Mainly out of principle. Also, some companies are paranoid about the idea of writing mp4 files with the phrase "com.apple.itunes" in it (I originally made the patch at the request of a company who was concerned about this), although this doesn't apply so much to Replay Gain.

I'm not aware of any programs that actually look for "com.apple.iTunes" specifically - it's just one subatom of the freeform metadata atom.

Actually, the 2 schemes can mix quite well. When MP3Gain/AACGain applies the gain, it also makes a corresponding change to the tags. For example, your replay_track_gain is -2.06. This means that your track is too loud, and the playing volume should be reduced by -2.06 dB.

The "global_gain" field that is modified by both programs has a resoultion of 1.5dB. So if you apply track gain your file, the gain will be reduced by 1.5 dB. The replay_track_gain field will be changed to -0.55.

If you play this track on a player that can not read the tags, it will play with a volume that is -.55 dB too loud. But that's normally close enough; some people believe that the human ear cannot detect volume differences of less than 1dB.

If you play this track on a player that can read the tags, the remaining -.55dB will be adjusted, and the volume will be exactly as David Robinson intended.

Hope that helps...

Dave

All,

My apologies in advance for the massive post which follows...

@Roland Online,

I recently made the switch from MP3 to AAC, and I put together a ripping scheme very much like yours (EAC+REACT2, Nero AAC v1.0.7.0, AACGain v1.7). In the process, I ran into some unwelcome tag behavior (as you did) and spent a bunch of time digging into it. After considerable way too much research and testing, I found is that there is a further problem/exposure here for Nero/AACGain users that seems to have gone unnoticed here, but needs to be discussed. I don't know if you are still using neroaacenc+neroaactag+AACGain, but I thought I would give you (and everyone else who is using a scheme like ours) a heads-up regarding my findings. I don't really know if this is an "AACGain issue" or "Nero issue" or "mp4v2 issue" or something else - so I will be interested to hear thoughts from Dave Lasker and others here about what I have found and what the "right solution" really should be (meanwhile I will mention a few workarounds that I found).

You noted above that fb2k was not seeing your Replaygain tags that were written by AACGain, but the problem goes deeper than that - according to my testing, I found that fb2k will also remove these AACGain tags on any tag update that you might do in the future (this will be true for any Nero AAC file created with the raw neroaacenc commandline encoder and/or tagged with neroaactag which is then immediately process with AACGain). So in this scenario, if you edit a song's tags with fb2k to fix a genre or a song title, you will lose your AACGain tags. Further, the problem is not limited to fb2k - I found at least one other tool with exactly the same behavior (the widely-used Mp3tag program), so there may be more tools out there as well with this behavior. Of course, unintentional removal of AACGain tags from my files presents me with two primary problems - first, I am no longer able to utilize Replaygain for playback (unless Replaygain scan is done again to put the tags back); and second, if I have applied a gain change with AACGain, I will have lost my AACGain Undo tags (so now I cannot be sure that AACGain can exactly reverse the gain changes at some future time, unless I just happen to remember what gain I applied to a particular file). FYI - my testing was with fb2k v0.9.4.3 and Mp3tag v2.38...

So according to my testing, this is what actually happened in your scenario above - when you did the Replaygain scan in fb2k, this caused fb2k to perform a tag re-write. After the re-write, the only Replaygain tags you had left were the ones created by the fb2k Replaygain scan - the tags from AACGain were never seen by fb2k, and were wiped out in the re-write. This behavior was not specific to the fact that you were doing another Replaygain with fb2k - this would have happened with any tag update you might have done.

So after a lot of fumbling around with neroaactag and AtomicParsley, I found my workarounds. Short version: any AAC files created by neroaacenc and/or tagged with neroaactag will have an additional atom in the Mpeg-4 container (this atom is called "moov.udta.tags"). This atom must be removed from the Mpeg-4 container prior to running AACGain, in order for the AACGain tags to be visible to fb2k/Mp3tag/etc., and for the tags to be persistent across tag re-writes by those tools.

Longer version: once I determined that fb2k and Mp3tag were clobbering my AACGain tags, I was able to narrow down the cause by using a handy AtomicParsley display option ("-T"), which displays the Mpeg-4 "atom tree". First, I created a new Nero mp4 file (including AACGain scan tags) with my REACT script, displayed the atom tree with atomicparsley -T, and saved the display results to a file. I then re-wrote the tags in the file with fb2k, ran the atomicparsley -T display again, saved the results, and compared the two displays to see if I could detect what had changed. What I found is that the "raw" Nero file contained the atom "moov.udta.tags", but the fb2k re-written file did not (this was also the case when I re-tested with Mp3tag). So both fb2k and Mp3tag found it important to remove this atom (or their underlying tag-writing libraries did).

I then speculated that maybe I could get everyone to play nice together if I made sure this atom was removed before AACGain was run. So I created a new mp4 file without AACGain scan, removed the suspicious atom with another handy AtomicParsley function that I found ("--manualAtomRemove"), ran AACgain against the file, and then viewed the tags in fb2k/Mp3tag. Lo and behold, all the AACGain tags were visible, and also persistent after tag re-writes by both tools.

So this was starting to seem like a feasible workaround to me, but I became concerned over whether it was really "correct" to remove this atom. I became more comfortable with this after testing a few more things. First, the iTunes encoder never creates this atom - it is specific to the Nero encoder (I tested by ripping a song with iTunes and inspecting the atom tree). So for anyone concerned with iTunes/iPod compatibility (but wanting to use Nero encoder), it seems to me you are actually creating a more compatible M4A file by removing this atom. I then ripped a song with fb2k converter + Nero encoder, and interestingly, the resulting file also did not contain this atom. Because I have heard that the fb2k developers have been champions of the Nero encoder, this also makes me more comfortable with removing the atom (hey, this must be correct - even the fb2k converter does it!). As to what this atom is actually for, and why the encoder puts it in (just to be removed by fb2k/Mp3tag/etc), I have a theory (if my theory is right, this atom is unnecessary for single-track single-chapter mp4 files, which is all I am using anyway), but I am hoping that one of the experts here can give a definitive answer...

So how does one remove the moov.udta.tags atom from a Nero mp4 file and get all the tools playing nice together again? Here are the workarounds that I found, in case anyone wants to implement one of them into their own REACT (or other tool) scripts. The first one I started to use is kind of obvious - you simply add the atomicparsley --manualAtomRemove step after your neroaactag step. Here are the actual script lines that worked for me (in my REACT2 track-cfg script):

AtomicParsley.exe "%TrackName%.m4a" -o "%TrackName%_temp.m4a" --manualAtomRemove "moov.udta.tags"
MOVE /Y "%TrackName%_temp.m4a" "%TrackName%.m4a

I eventually settled on a different workaround which is one step simpler than the above. Instead of tagging with neroaactag and then removing an atom with AtomicParsley, I wondered if I could do both in one execution of AtomicParsley. The track-ripping script that comes with REACT2 is actually coded to use AtomicParsley instead of neroaactag to tag Nero files, but I initially changed my script to use neroaactag after finding that fb2k could not read the AtomicParsley-created tags. However, it now occurred to me that the moov.udta.tags removal might fix this as well (turns out that it does). So I got to looking at the AtomicParsley help displays, and found a parameter to add to the tagging command that will remove the moov.udta.tags atom while writing the tags. So if anyone wants to implement this version of the workaround - just add the following parameter to your AtomicParsley tagging command: "--foobar2000Enema" (this basically does the same "enema" that fb2k does when it re-writes a tag - removes the moov.udta.tags atom).

Use either of the above methods before you run AACGain, and your AACGain tags should now be safe out in the wild. However, as I mentioned, I consider this to be more of a workaround than a real solution - I would really love to hear from the experts here as to what is really behind this problem, and what those people think a more elegant solution would look like (ie, one that just gets all the tools playing nice again right out of the box). Speaking as someone who has become a big fan of this Nero encoder, I truly want to see it's use grow and prosper, but it troubles me to see scenarios like mine where people may decide not to use this encoder because they perceive tagging incompatibilities (I almost gave up on it myself due to this problem, and probably would have had I not become comfortable with my workarounds when I did).

@davelasker - can't thank you enough for the great tool! I would not have made the switch from MP3 to AAC if AACGain did not exist. Until we see Replaygain supported on the majority of portable DAPs, I'm sure I will continue to use your tool religiously...