We use mAirList with a mix of FLAC and MP3 files, and would like to have all files pre-levelled.
For FLAC files, mAirList correctly reads the “REPLAYGAIN_*” tags and applies them as an amplification value, exactly as required.
With the MP3 files, I’ve been unable to have mAirList use any kind of gain information.
mAirList doesn’t seem respond to information in an APEv2 tag (applied using mp3gain) nor information in a LAME tag (applied using the ‘lame’ command). Both of these result in an amplification value of 0.0 when loaded.
What format does mAirList expect the ReplayGain information on an MP3 file to be in?
Generally speaking, the problem about ReplayGain is that there is absolutely no standard. Each format is using its own tagging mechanism, and sometimes there’s even more than one possibility for a single audio format, most notably MP3: ID3v2 tags, APEv2 tags, and the LAME header.
This debacle is why I use MP3Gain to permanently change the level of my MP3 files. You then have no tags to worry about, and all programs which play MP3s will play them at the correct level.
To do this in MP3Gain, click Options, Tags, Ignore. Be aware, as I say, that ALL level changes are then PERMANENT and cannot be undone. If this bothers you, work with copies of your MP3s.
If mAirList can honour the APEv2 tags then that would certainly be beneficial, as files labelled with mp3gain would then work directly.
Although right now the commercial music distributor we use sends over files with the LAME tags. I was hoping to be able to use these files directly and without modification – that would be ideal. But it’s reasonable that you can’t do this without support from BASS.
At least now I know that ID3v2 is supported then perhaps I can integrate some kind of translation from the LAME or APEv2 tags into our workflow.
Modifying the MP3 frames themselves is rather a hack and in my mind a recipe for problems. Whilst there maybe isn’t a single standard for the gain tag, there’s enough here to make for a good working system.
After some experimentation, I found that later versions of mp3gain have an option to store the data in an ID3v2 tag.
It seems that the useful gain information goes successfully (look like it’s in an ‘RVA2’ frame), but amplification in mAirList still comes out at 0.0. So I’m still stuck; no MP3 file I’ve tried has been able to modify the amplification value.
Thanks for the link to the Foobar information. I can’t see anything that indicates exactly what tag is required from it though. Can you clarify which tag or field is required? Thanks.
# Check the ID3v2 tag information using mp3gain
$ mp3gain -s c -s i "50 Cent - Ayo Technology (Clean).mp3"
50 Cent - Ayo Technology (Clean).mp3
Recommended "Track" dB change: -9.619141
Recommended "Track" mp3 gain change: -6
Max PCM sample at current gain: 36782.000000
Max mp3 global gain field: 255
Min mp3 global gain field: 140
# Check using eyeD3 (although it doesn't seem to interrogate the RVA2 frame)
$ eyeD3 "50 Cent - Ayo Technology (Clean).mp3"
50 Cent - Ayo Technology (Clean).mp3 [ 6.72 MB ]
-------------------------------------------------------------------------------
Time: 04:11 MPEG1, Layer III [ ~224 kb/s @ 44100 Hz - Joint stereo ]
-------------------------------------------------------------------------------
ID3 v2.4:
title: artist:
album: year: None
track:
UserTextFrame: [Description: MP3GAIN_MINMAX]
140,255
[quote=“Torben, post:7, topic:7662”]Ok, I see a MP3GAIN_MINMAX frame in the ID3v2 header - but none of the REPLAYGAIN_* frames?
What’s the purpose of the MP3GAIN_MINMAX field anyway?[/quote]
No idea! Perhaps it is additional information required by mp3gain for its ‘undo’ feature (when modifying the actual MP3 data) It seems that the /real/ gain information is in the RVA2 frame of the ID3v2 tag.
So if I understand correctly, you’re saying that mAirList is looking for the gain information in UserTextFrame containing labels REPLAYGAIN_*. I’ve not yet encountered a tool which puts the information there.
I’ve got this working, by copying existing gain information into the ID3v2 tag as a UserTextFrame. mAirList picks up this value and uses it as amplification.
It’s a bit of a workaround, it would certainly be more desirable for mAirList to find information in the LAME, APEv2 or ID3v2 tag. But this is only because these seem to be the standard ones added by other applications.
For information, I made a quick script on Linux to tag the files. I’ve posed it here in case it is useful to show what’s needed:
#!/bin/sh
#
# Copy level information from existing tags into a format which
# is understood by mAirList
#
EYED3="eyeD3 --no-color"
if [ -z "$1" ]; then
echo "Usage: $0 <file> [...]" >&2
exit 1
fi
RC=0
for FILE in "$@"; do
# Primarily look for the LAME tag
GAIN=`$EYED3 --lametag "$FILE" | \
sed -n 's/^Radio Replay Gain.* \([0-9\.-]\+\).*/\1/p'`
# Fallback to an APEv2 tag (eg. added by mp3gain)
if [ -z "$GAIN" ]; then
GAIN=`mp3gain -s c "$FILE" | \
sed -n 's/Recommended "Track" dB change: \([0-9\.-]\+\).*/\1/p'`
fi
if [ -z "$GAIN" ]; then
echo "$FILE: no gain information in file" >&2
RC=1
else
$EYED3 --set-user-text-frame="REPLAYGAIN_TRACK_GAIN:$GAIN dB" "$FILE" > /dev/null
if [ $? -ne 0 ]; then
RC=1
fi
fi
done
exit $RC
Well, I know that MP3Gain writes its ‘undo’ and ‘analysis’ tags in APEv2 format, and always has done. This was a design decision made in the early 2000s to specifically avoid causing problems or’interfering’ with other tag formats such as ID3v1.
I just did a test here on an MP3 file using MP3Gain, and in its standard setup, it writes four APEv2 tags: MP3GAIN_MINMAX and MP3GAIN_UNDO (which are indeed concerned with reversing or undo-ing MP3Gain changes), REPLAYGAIN_TRACK_PEAK, and REPLAYGAIN_TRACK_GAIN.
BUT remember that these tags are purely for MP3Gain internal use! Mp3Gain does alter the Global Gain field within each frame in your MP3 file. So, the presence or absence of a tag is irrelevant; MP3Gain alters MP3 files at a much deeper level which you would not detect, unless you did a frame-by-frame analysis of an MP3 file. As I said before, I personally use MP3Gain totally without tags, as I do not ever need to be able to undo its changes; but it WILL still apply the Global Gain frame changes when I run it.
What this means in practice is that mAirList (or any other MP3 player) should NOT be attempting to change the level of MP3Gain-processed files further by looking for and applying tags, because the level change HAS ALREADY BEEN APPLIED INTERNALLY within the file’s frames. ALL that a player needs to do is to decode and play the file in the normal way, and the level will take care of itself.
Therefore, when mAirList (or any other MP3 player) loads a file altered by MP3Gain, it will play at the intended, internally altered level; and all such files will show up in mAirList with Amplification of 0.0 and this is correct.
As you have already said that your FLAC files are being handled correctly (and obviously, FLAC uses a different means to set a ‘global’ file gain change which DOES require the use of tags, unlike MP3 files), your only problem might be if you use a tool other than MP3Gain to set the level of your MP3 files.
I just did a test here on an MP3 file using MP3Gain, and in its standard setup, it writes four APEv2 tags: MP3GAIN_MINMAX and MP3GAIN_UNDO (which are indeed concerned with reversing or undo-ing MP3Gain changes), REPLAYGAIN_TRACK_PEAK, and REPLAYGAIN_TRACK_GAIN.
Perhaps our versions of mp3gain differ here because in my case I do not get the REPLAYGAIN_* fields (I use v1.5.2 by Glen Sawyer)
It also does not modify the MP3 frames unless I specifically ask for this behaviour (using the “-r” or “-a” flags), so the default it to only apply a playback level in the tag. But this is definitely the desired behaviour for me, and is in-line with the ReplayGain proposal and its implementations with other file formats (eg. FLAC, Vorbis).
Modifying the MP3 frames is a clever trick, but not desirable. For example it fixes one choice of track/album gain, clipping behaviour and reference level. In our case the files are used across more than one application, sometimes with differing reference levels.
I’m relatively happy with mAirList treating the REPLAYGAIN_* fields in the same as for other file formats, assuming this is a standard of some sort.
It’s even better if mp3gain actually adds these tags. But it runs a risk if it applies a change both as a tag and to the MP3 frames, because the level given in the tag no longer corresponds to the audio.
My version of MP3Gain is 1.2.5 for the GUI program; the back end is v1.4.6.
The four tags it creates are for internal use by MP3Gain, and exist ONLY so that you don’t have to re-analyse the file (with MP3Gain) if you want to undo or change the gain again at a later time. The tags written by MP3Gain are not any kind of ‘standard’ replay gain tags as implemented by other file types.
The Concepts page of MP3Gain Help file specifically states that MP3Gain DOES alter frames in MP3 files, and I don’t see any switches (of ‘flags’ as you call them) that I can modify to change that. If you don’t write changes to the frames when you use MP3Gain, then in effect, MP3Gain is doing nothing to the file; it’s just storing its findings in its ‘proprietary’ tags (if you write those) and thus is NOT changing the gain of the file: the gain will be the same as when you started. This may explain why you are finding levels of your MP3s are ‘wrong:’ i.e. unchanged from the original gain?
I’ll repeat: the tags written by MP3Gain DO NOT relate to the current level of the file (only the Global Gain fields in the frames indicate that), the tags are ONLY there so that MP3Gain can quickly and easily undo or alter the changes it makes to the frames within MP3 files, and the tags are NOT intended for other programs to use to ‘modify’ the gain of the file during playback (as you say, if programs did that as well, the levels would be wrong). You can ask MP3Gain not to write any tags (my standard usage!) and it still works just as well. Its PRINCIPAL job is to modify frames! This is all explained in the MP3Gain help file, and in the FAQ on the MP3Gain site.
PS: If you do request MP3Gain to write its ‘undo’ and ‘analysis’ tags, remember they are APE tags and not ID3 tags.
Perhaps it is additional information required by mp3gain for its ‘undo’ feature (when modifying the actual MP3 data) It seems that the /real/ gain information is in the RVA2 frame of the ID3v2 tag.