When m4a files get processed their original creation date gets changed!

[Zeddd-3d]

I've used this helpful application for years with Mp3s and AS EXPECTED the original creation date of the file is never changed when you alter the volume of the file.

But I just updated the application so that I could also process m4a files (which was not working on my previous older version 1.5) and unfortunately both v2.5 and v2.3.4 have the same issue of processing the m4a files and changing both the creation date and modification date to be the current date and time. The creation date should not be altered, or the user loses track of when the file was actually recorded.

The Mp3 files still get processed properly. Is there something about m4a files that make them different than mp3s in the way they respond to being processed? Or is this an oversight and correctable issue?

Sadly I didn't realize this way happening until after I had processed a few files and forever lost their original recording date and time. I am not going to be able to use it for m4a files unless this problem can be fixed (unless I process the files immediately after I record them so that they still have a reasonably accurate creation date).

Great application and very helpful. I hope you can fix this!

Thanks in advance,

Zeddd

[Zeddd-3d]

In addition, I've noticed that with BOTH m4a and Mp3 files, if we simply choose to "Analyze Only" the file modification date is irreversibly changed, even though we haven't yet altered the file.

That is not ideal behavior. The modification date should not be altered unless we change the file, and even if it is technically altered for the moment while it is being analyzed and potentially about to be altered, it should go back to the previous modification date if we decide not to actually process the file.

I often sort recordings by Date Modified, so just analyzing a recording with Mp3GAIN now causes it to move to the top of the list.

This is much less of an issue than the first one above, but if there is a way to easily address this as well while you're looking at these DATE-related things, it would be awesome. Thanks!

[Sappharad]

The Mp3 files still get processed properly. Is there something about m4a files that make them different than mp3s in the way they respond to being processed? Or is this an oversight and correctable issue?

The versions of MP3GainExpress with AAC support are just calling the command line version of AACGain in the background. Any weird behavior with files would also occur in the original AACGain app.

If I recall the description of the process correctly, I think the MP3 modification process is very simple and the app is able to make changes without re-encoding the entire file. There is a loudness value in each chunk that just needs to be updated. But AAC works completely differently and has no equivalent thing; it was my understanding that the entire file has to be re-written although it doesn't have to be recompressed.

In other words, the problem probably originates upstream and I'm not sure without looking what work would be required to correct it. I did go back to the original AACGain and submit a bug fix to them about 4 years ago for a different problem, but I don't know how easy this one will be and probably won't have time to look for it in the near future.

I've personally found that MP3Gain is no longer useful to me. The way albums are mastered nowadays, they intentionally crank up the perceived loudness such that if you buy something older that isn't mastered that way and try to use MP3Gain or AACGain to raise the volume as high as it goes without clipping, the music still sounds quieter than pretty much every album I've purchased in the last 4 years. Nowadays I end up using the "Loudness Normalization" feature in Audacity to make quiet stuff match the excessive loudness in new albums just so my music library on shuffle is consistent.

I'll keep this open, but have no clue when I'll look into it.