So I have many CDs that are not normalized. Re-ripping is a very tedious process, and since a lot of my CDs got stolen a while back it is downright impossible. I tried voladj but was not happy with it since it handles songs with large volume shifts very poorly. I would much rather the Empeg do normalization on the fly for me.

Ok, so that would be hard. It would have to completely read the next song on the playlist, analyze it to find the peak volume, and create an adjustment factor, all while the previous song is still playing. It would take a lot of memory, have to be built into the player software, and of course there are time when it would be impossible. But I had another idea, and one that I think could be done via a user mod.

What if we created our own database, or somehow modified their database, to hold normalization information. The first time through the song would be played normally, but as the song is playing we would intercept the data stream and check for the high volume point. Once the song is over, we write this info to the disk and keep it around for the next time we play the song. The next time that song is played, we use that information to normalize the song as it is being played, similiar to the way voladj does now, but with better information to work on.

Doable? I realize there is in issue with the read-only hard drive. Is it a major obstacle with no way around it? What do you'all think?

Toby already has code that does this. It's in the current beta, but disabled due to bugs.

What if we created our own database, or somehow modified their database, to hold normalization information. The first time through the song would be played normally, but as the song is playing we would intercept the data stream and check for the high volume point.

Kinda like this "feature" that was included in 2.00b3 but didn't work very well? It tried to find the peak level and save it with the track's metadata, so the next time you played the track, it would be normalized.

Unfortunately it didn't exactly work all the time and sometimes caused severe distortion/clipping. Not sure if it's been touched since, or might make an appearance in a future beta. Someone on the inside might clue you in if they happen upon this thread, though.

> Kinda like this "feature" that was included in 2.00b3 but didn't work very well?

Yeah, kinda like that, but working. 2.0b3 was slightly before my time here (Jeez, have I only had the Empeg for 4 months???? Seems like forever.)

Figures the Empeg guys would have thought of this, they thought of everything else. Toby, could you please please try and put it back for me, it would be very cool.

In reply to:

---

Kinda like this "feature" that was included in 2.00b3 but didn't work very well? It tried to find the peak level and save it with the track's metadata, so the next time you played the track, it would be normalized.

---

This would be cool, but something more like the dynamic compression feature in normalize would be cooler. It's probably floating point, though

Er, um, dynamic compression is already on the Empeg in the form of voladj... Or did I miss some whiz-bang feature of that "normalize" you linked to?

Voladj can't do what normalize does, though, because it can't know what overall adjustment level to use for a song

I think you're confusing normalization with dynamic compression. Normalization will not make your songs all seem to play at the same volume. Applying a single overall adjustment level to each song isn't going to solve that problem, only dynamic compression can.

Did you read this stuff?

In reply to:

---

think you're confusing normalization with dynamic compression.

---

"normalize" the program, not "normalize" the algorithm. Sorry for not being clear. It's clear that "normalize" the program does dynamic range compression (it's been the default, instead of true normalization) since 0.6. The README from the package has all the dirt.

The current version even includes an xmms plugin which does what I want, namely, honors (and can compute and insert) RVA2 frames.

Gah. The xmms module honors and "normalize" can compute and insert...

What clarity of content?

> Normalization will not make your songs all seem to play at the same volume. Applying a single overall adjustment level to each song isn't going to solve that problem, only dynamic compression can.

I think that is overstating the case a little bit. It will not completely solve the problem, but will greatly help. I have found normalization to be quite good at making all my songs play at the same volume.

You're right in what you say about the voladj stuff. At the moment it looks into the future just a little bit when it makes a decision about how to scale the sound. If I (or somebody else) was feeling like nutting out the complexities we could make it look 5 times further into the future. However, that's still only about 1/10 of a second.

The problem with during a more complete treatment is that it's hard to wedge it into the kernel. Something significantly better is probably more suited to living in the player.

Richard.

Hi Richard!

>The problem with during a more complete treatment is that
>it's hard to wedge it into the kernel. Something significantly
>better is probably more suited to living in the player.

Something to keep in mind here is that, when the player is running, it is locked into memory exactly the same as the kernel is. So for most purposes, there is a very blurry line between the two, and it probably doesn't really matter (from a memory standpoint) which of the two implements any given feature.

But doing something that is TIME CONSUMING is best left to the multi-threaded player, than to the kernel where things are ALWAYS single-threaded on the Empeg.

Now that I've got that away, here's how to do this for Real:

Hijack can easily intercept the disk reads of music files, and could scan the file as the player reads it. If someone were to write some logic to partially decode MP3s on the fly for this, then Hijack could measure the min/max/average levels of an MP3 as it is being read from disk by the player software. Hijack could then "remember" these values until the track is later played by the player (using the FID to keep track of which is which). This information could then be used to do "on-the-fly" normalization if we wanted.

Of course, for LARGE files, they may begin playing before the normalization data has been completely gathered, but we could just use what we've got by that time, and adjust it on the fly.

Now there's a programming project for someone. If somebody here puts together some C code to scan an MP3 file and measure min/max/average audio levels (and perhaps the standard deviation as well), then I can incorporate into Hijack, and from there it's easy enough to do "on-the-fly normalization".

Cheers

Mark

Maybe you're already well aware of this, but there's a guy out there who has been trying to develop a standardized method of dealing with this problem of apparent volume differences between individual MP3 songs.

His project is at this URL:

http://privatewww.essex.ac.uk/~djmrob/replaygain/contents.html

He already wrote some Windows software that performs statistical analysis on an MP3 file compared to pink noise and comes up with the correct value to achieve a standard 83db of gain for the file. It looks like he's been trying since mid 2001 to get people to adopt his standards into an MP3 player program.

Replay Gain sounds like a great idea. I wonder if it, or something like it, will ever get any support.