Support ID32 box for MP4/ReplayGain tags

[Hendrik Schreiber]

Players like VLC are able to interpret ReplayGain tags. For MP4, these tags have to be embedded into a ID32 box—basically, just like for WAV, the whole ID3 stuff can be embedded into one ID32 atom.

So it would be nice to have support for reading/writing such a ID32 box.

References:

• http://mp4ra.org/specs.html
• http://wiki.hydrogenaud.io/index.php?title=ReplayGain_1.0_specification#Metadata_format
• https://forum.videolan.org/viewtopic.php?f=2&t=138299

[IJabz]

Is it just VLC that reads replay gain in mp4s this way, what does iTunes do ?

[Hendrik Schreiber]

It's in the ReplayGain specification that applications should read/write ReplayGain that way. So I assume many other applications do the same thing.

AFAIK, iTunes does not honor regular ReplayGain tags at all. It uses its proprietary iTunNorm/SoundCheck thing.

[IJabz]

okay I see, so the question is what else is the ID32 box used for, what happens if we have mp4 and id3 value for same field, or it just commonly used for replaingain, more research is needed.

[Hendrik Schreiber]

Frankly, my preferred scenario would be, that players like VLC simply support reading the ReplayGain tags from the ILST atom, as that's where we write all the other info, it's easy to parse and already implemented. AFAIK, Foobar2000 writes the tags there, too.

[Xerus]

I wrote a little method that extracts the replaygain from a given Tag using regex. It is forceful and probably not the most efficient way, but it should work for every format you encounter and every specification:

private static final Pattern getGain = Pattern.compile("-?[.\\d]+");
    Iterator<TagField> fields = tag.getFields();
    while(fields.hasNext()) {
        TagField field = fields.next();
        if((field.getId() + field.toString()).contains("replaygain_track_gain")) {
            Matcher m = gainPattern.matcher(field.toString());
            m.find();
            System.out.println(m.group());
            replaygain = Double.parseDouble(m.group());
            break;
        }
    }
}

kinda bugged me that there is no built-in support, what about including it with the notion that it's not fast?

[IJabz]

Xerus2000 , this commit https://bitbucket.org/ijabz/jaudiotagger/commits/a74a0d697d5d7da554907ef9ae64c76f4cb094b5 shoudl give you the idea of how to properly add a new field over all formats if you would like to submit a pull request.

[Xerus]

It isn't meant to be a field, because implementations still differ everywhere. It could be a default function within the Tag interface.

[marcoc1712]

@Xerus2000 you mean

a. KEYS REPLAY_GAIN_ALBUM, REPLAY_GAIN_TRACK, REPLAY_GAIN_ALBUM_PEAK, REPLAY_GAIN_TRACK_PEAK should be mapped to different TAGS FIELDS in the same TAG Type and version

or

b. We need to have different KEYS (i.e. ITUNE NORM) becouse same conceptual information is named differntly by different applications?

I think is b, but I know some other KEY (I.e. PERFORMER or TEMPO, OCCASION, ...) are mapped to ILPS, COMM or others in jaudiotagger, when foobar (to name one) populate TXXX frames.

I do think this is quite common and I suggest to apply a generic fault back solution: alwais look at TXXX frames for TAGS expected to be in 'non common' frames and not found. That way, b will be solved (not only for replay gain).