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