Read replaygain from Tag and adjust playback volume accordingly

[xeruf]

This is the function I use to find the ReplayGain. Since where to write them differs widely, it iterates over all tagfields and applies regex matching (tag needs to be an instance of org.jaudiotagger.tag.Tag)

private static final float defaultGain = -6;
private static final Pattern gainPattern = Pattern.compile("-?[.\\d]+");
private float extractReplayGain() {
	try {
		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();
				float replaygain = Float.parseFloat(m.group());
				return replaygain;
			}
		}
	} catch (Exception e) {
	}
	return defaultGain;
}
float gain = (float) Math.pow(10, extractReplayGain() / 20);

Then you just need to multiply the volume with the gain and you are ready to go!

[sghpjuikit]

This involves several separate functionalities:

• read replay gain
• be able to display reply gain as a column
• write reply gain if user specifies
• use replay gain data to adjust playback volume

The features are doable, but require understanding about manipulating and displaying the reply gain values, its unit, etc.

The code shared does appear to misuse toString() method and also has a terribly inefficient if statement which calls toString() for every field present in the tag.

This feature is blocked by porting the classes extending Item and ObjectField to Kotlin, which promises to make adding new fields to songs more effortless and most importantly consistent when it comes to handling the field's value.

[xeruf]

I forgot one important step! See the last codeline in my first post!

Yep, the method is not very fast, but a TagField has no "getValue" method. To get started, an option to enable it for playback should suffice, because then it can just be lazily loaded.
For a performance perspective: after analyzing over 1000 Songs in my library, the time this function needed averaged out to about 20,000 nanoseconds

Reading and displaying ReplayGain values should be scheduled later down the line, because displaying is generally not really needed and scanning is hard to integrate, so it can be outsourced to external Tools for now.

As for the values: The Tag contains a float that scales the volume of the Song to a reference volume of 89 dB. This is the value distribution for my tracks(rounded to integers):

As you can see, positive values, which correspond to a gain >1 are rare, but happen.

[sghpjuikit]

I do not like the idea of on demand here, because the io is involved and thus worker threads will be involved (to make sure main thread does not block) and that makes code more complex than necessary.

Due to the design of the Metadata class, this is a do-all-or-nothing kind of feature and blocked by a refactor. I'll look into it soon.

[xeruf]

why is there IO involved? Don't you store a Tag object for each Song in the database?

[sghpjuikit]

You said: "an option to enable it for playback should suffice, because then it can just be lazily loaded." This means the replay gain value would be loaded from tag of the file each time the played song changes. If the value should be read once and stored in a Metadata object (and persisted in db), then it is no longer lazy and this solution is the one that is blocked by a refactor.

This issue can be worked on now, the refactor has been done - Metadata class is in Kotlin, with much needed code improvements, like: using null as an empty value uniformly across all Metadata fields.

[sghpjuikit]

Pls answer some of the questions:

• what is the unit? is the value an integer value? Can it be represented by Long or does it need Double?
• is replay gain value range unlimited? [-infinity, infinity]? If not what is the range (not usual use case but theoretical specification)

Also

• We need to also support album replay gain.
• Perhaps supporting tag read/write is enough if vlc could take care of replay gain on its own. This would be ideal. Can you investigate if that is possible?

The Tag contains a float that scales the volume of the Song to a reference volume of 89 dB

What does that mean for playback? Because

float gain = (float) Math.pow(10, extractReplayGain() / 20);

will mean that if the song is already 89 dB, it will have gain of 1 correct?
In that case we just apply the volume as if there was no gain, but what volume should that be? We have no concept of dB in the volume value!

For instance if user sets volume to max, multiplying with >1 gain will have no effect correct? That isnt very helpful and makes the feature look buggy to me.

[sghpjuikit]

http://wiki.hydrogenaud.io/index.php?title=ReplayGain_1.0_specification