I have been working with Spooky (see his post below). I am not yet able to reproduce his problems, but it there is clear evidence that running AACGain has corrupted some of his audio files. I would advise all users of AACGain to have a verified backup of your files before using it.

I'll report later after we have more data.

Thanks!

Dave

Let me just add that Dave is being a tremendous help in assisting me with my issues!!!

Also, the ‘corruption’ issue is not major, but does appear possible. In AACGain’s defense, there were only a handful of files that had this corruption issue out of a total of about 11,000. So again, while not widespread at all, it is a possibility.

I gave Spooky an experimental version of AACGain 2 weeks ago, and it appears to be holding up.

However, another user reported that files processed by AACGain would not play on an iPod Shuffle, although they played fine on iTunes and on my 3G iPod. This appears to be caused by the mpeg4ip/mp4v2 library updating the following mp4 properties: bufferSizeDB, maxBitrate, and avgBitrate. These are recomputed from the actual data in the file when it is closed. It appears the IPS doesn't like the recomputed values; it can deal with only the original values as computed by iTunes. I imagine that other mp4 encoders will have similar problems with IPS.

I'm completing testing of a version 1.3 that corrects this problems and hope to release it soon.

thanks for your efforts Dave

Just a note, I encountered the exact same problem. Corrupted files would not play on my 3G iPod or Shuffle.

If you get bit by this, here is how I recovered -

(1) did a huge constant gain drop (-11dB in my case)
(2) re-ran a analysis to bring the gain back up
(3) take careful note on paper which files would not be changed by the analysis
(4) applied the gain
(5) went through the list taken in #3 and reapplied a minimal constant gain drop

...as I discovered that doing #5 will make the files playable again (if a little softer).

Cheers
SS

Can you email me a corrupted file, as well as original as ripped from CD, so I can confirm if this is the same or a new problem?

Thanks!

Dave

I'll try. I just spent a bunch of time fixing them so now I will have to intentionally corrupt one... give me a day

SS

Whatever it worth - I had this problem today too, but now I think this is more like iTunes/iPod issue.

1. I converted some files to aac 256 with iTunes.
2. Then launched aacgain on those right in iTunes library.
3. Immediately after that I transfered them from iTunes to iPod and disconnected it.
4. iPod (3G) doesn't play them - just skipping one by one.
5. Plugged iPod back and rescanned those tracks (selected them all, Get Info, marked Comment field and Ok). After that iTunes changed bitrate values from 256 to some others.
6. Now iPod plays them fine.

So I think when I transfered modified files iTunes used some old data from it's database for creating records in iPod database and since this data was out of sync with actual files iPod had problems and rescanning brought tracks and database back in sync.

After much hair-pulling, and with the help of several iPod-Shuffle-endowed users (unfortuantely I don't own one), I got to the root cause of the problem:

In an mp3 file, the metadata tags (i.e. song name, album, artist, etc.) are stored at the end of the file after the digitized audio. This allows them to be modified or expanded without touching the audio part of the file.

AACGain and mp3gain both add additional custom metadata tags to save the results of analysis and undo information in the file.

In mp4/m4a files as created by iTunes, the tags are near the beginning of the file inside the 'moov' atom. There is an empty 'free' atom after the tags. When tags are added in iTunes, the tag data expands, and the free atom shrinks, allowing tags to be added without rewriting the entire file.

The mpeg4ip/mp4v2 library used by AACGain doesn't work that way. When tags are changed, the entire atom containing the tags is replaced by a free atom, and a new atom for tags is written to the end of the file, after the digitized audio.

A file in this non-standard order can be played on iTunes and older iPods, but will not play on the iPod Shuffle.

The mpeg4ip/mp4v2 library includes an 'Optimize' function, which rewrites the file in the normal order, with the tags in front of the audio. When the output from AACGain is Optimized, it will once again play on the Shuffle.

When AACGain is run from the command line with the /t (Use Temp File) option, it uses the Optimize function to rewrite the file. When I use AACGain myself, I always run it from the command line, so I never saw this problem.

However, the MP3GainGui.exe program, which most users use as a front-end to AACGain, doesn't pass the /t option under all circumstances. So many users unexpectedly got files in the "bad" order. However, in some cases it would pass the option, resulting in the "bad" files getting fixed.

Another result of the missing option is that if AACGain is ever interrupted mid-file, the file could be left in a corrupted state. I believe this is the cause of very sporadic corruption that only 2 users have reported.

The fix is very simple - I am changing AACGain to always ignore the setting of the /t option, and to always use a temp file and Optimize.

Once the new release is out (should be by this weekend) anyone with a misordered file will be able to correct it just by processing it again.

Thanks to all the users who helped me through this!

Dave

Thank you for all your efforts! I have couple of questions though :)

1. What about instructions and Makefiles to build it on unix platforms? I tried to build CVS version, but it's far from obvious now...

2. That -t option - with version 1.2 if you launch aacgain on group of files it will first create temp. files and erase/rename only when all of them adjusted. So while in process it consumes space equal to size of the file group. This looks logical when adjusting with -a option - even though this is disadvantage, it helps to keep the group consistent if aacgain canceled and this option usually used on small amount of files. But for -r option, which may be used on huge collections, it looks more logical to erase/rename as soon as original file processed, because in this case if aacgain canceled it can be relaunched later without loosing results for already finished files.

Don't forget to mail me a Win32 binary for RareWares

I have completed the 1.3 release of AACGain which addresses the problems referred to in this thread. I emailed rjamorim a copy so it should be available on rarewares soon.

For those want to build it themselves, the source code is now hosted on Glen Saywer's mp3gain sourceforge cvs repository . You'll need a cvs client to access the source.

These issues only impact iTunes issues on Windows so I haven't re-released the Linux version.

Thanks for your patience!

Dave

Just uploaded and announced it

As you imply this was done for the benefit of the -a option. Windows users don't have this problem since the MP3GainGui front end launches AACGain individually for each file when using the -r option.

Becuase of the way the option handling is done in the source file mp3gain.c, it's a bit of a pain to do what you are asking for. Since you are on Linux, can you use a shell script to run AACGain one file at a time?

Dave

I'm using it on Mac OS X and call it from 'find' for this reason, which is almost like from script. The only problem here is that now to make a bulletproof workflow with command line version people should use option -t and be aware that on large collections they shouldn't cancel and make sure that there is enough disk space or they may loose results for many hours/days of work. For me this is not a big deal, but this may be a problem for others because all these things are not obvious and not documented anywhere so far. In any case this is your decision to make and I really appreciate all that work you did on aacgain!

Andrey

With Version 1.3, you don't need to specify -t. AACGain 1.3 always uses a temp file regardless of whether or not -t is there.

Dave

Wait, you wrote you didn't re-release Linux version, so if I get it right we still should use 1.2 from that separate package you have on your web page? The CVS version at this moment doesn't have supporting Makefiles and documentation for Linux, so 1.3 cannot be "just built".
In any case this doesn't change anything - all hidden dangers of command line aacgain (and mp3gain?) are still there as far as I can see

For those who want a 1.3 Linux version just substitute the .h and .cpp files in the Linux aacgain source directory with those from sourceforge's cvs.

Dave