PDA

View Full Version : volume normalization



Michael Sigalos
2004-08-17, 08:26
I am not a fan of VN because (IMHO) it changes the overall sound of the
track. However, I too am often very annoyed at the changes in volume
between tracks, especially noticable are older ones versus current ones.

This isn't SlimServer's problem per se, but here is an idea that I will toss
out for everyone to throw up on (keeping in mind I know nothing of audio
formats or the detailed specifics of how a normalizer does what it
does)...

Couldn't a "normalizer" be developed that would scan each track of the
library but instead of making a change to the source material
(undesirable), it would simply store a "relative volume value" (RVV) for
each track. For argument sake let's say the RVV would range from 1-100,
where 100 is a track that must be played at full relative volume and 1 is a
track that must be played at the lowest volume (i.e. 0 or 1). This value
could be stored in a track tag or perhaps better yet in the new SlimServer
database. The server would read this value and adjust the output volume of
each player accordingly. The server wouldn't have to resample the song,
just simply change the output volume of the player so the user doesn't have
to make the adjustment. To illustrate... I have my player's volume set at
6 and the NVV is 50... the server would adjust the output volume to 3.

Ok, I know it is more complicated than I describe, but something to preserve
the original source yet tackle the volume issue without burdening the server
with resampling would be a very welcome addition.


> anthony webb wrote:
>
> >does it work automatically with slim? or would I need to run it on my
> > files
> >before uploading?
> >
> >
> You need to run it before. It is once in a lifetime deal, where you run
> it once, and it LOSSLESSLY adjusts the volume. I has per album setting
> as well, which is great for classical and jazz fans, where a particular
> song is meant to be quiter than the rest of the album. I like this
> solution because:
>
> 1. lossless = does not mungle your bits
> 2. compatible with all mp3 playback devices (ipod, slim, winamp, etc)
> 3. album mode
> 4. analyzes songs per energy, not per peak volume
>
> Anyway check it out at: http://www.geocities.com/*mp3gain*/
>
> Pbox

Jason Holtzapple
2004-08-17, 08:31
Michael Sigalos wrote:
> Couldn't a "normalizer" be developed that would scan each track of the
> library but instead of making a change to the source material
> (undesirable), it would simply store a "relative volume value" (RVV) for
> each track. For argument sake let's say the RVV would range from 1-100,
> where 100 is a track that must be played at full relative volume and 1 is a
> track that must be played at the lowest volume (i.e. 0 or 1). This value
> could be stored in a track tag or perhaps better yet in the new SlimServer
> database. The server would read this value and adjust the output volume of
> each player accordingly. The server wouldn't have to resample the song,
> just simply change the output volume of the player so the user doesn't have
> to make the adjustment. To illustrate... I have my player's volume set at
> 6 and the NVV is 50... the server would adjust the output volume to 3.
>
> Ok, I know it is more complicated than I describe, but something to preserve
> the original source yet tackle the volume issue without burdening the server
> with resampling would be a very welcome addition.

You've pretty much described ReplayGain: http://www.replaygain.org/

There is good support in the FLAC format for ReplayGain and probably
other formats. There's an RFE open against SlimServer for ReplayGain
support - attach your email to the bug's interest list to show your
interest. :)

--Jason

James Craig
2004-08-17, 08:36
....and MP3gain uses the replaygain analysis and does pretty much what is
described below.
As I understand it a negative volume gain (or something similar) is
stored in the mp3 meta data - and as it's part of the MP3 spec it is
used by all players.

The original gain value is kept in the mp3gain logs (which is the only
problem I can see) and can be restored
- as long as you don't lose them.

James

Jason Holtzapple wrote:

> Michael Sigalos wrote:
>
>> Couldn't a "normalizer" be developed that would scan each track of the
>> library but instead of making a change to the source material
>> (undesirable), it would simply store a "relative volume value" (RVV) for
>> each track. For argument sake let's say the RVV would range from 1-100,
>> where 100 is a track that must be played at full relative volume and
>> 1 is a
>> track that must be played at the lowest volume (i.e. 0 or 1). This
>> value
>> could be stored in a track tag or perhaps better yet in the new
>> SlimServer
>> database. The server would read this value and adjust the output
>> volume of
>> each player accordingly. The server wouldn't have to resample the song,
>> just simply change the output volume of the player so the user
>> doesn't have
>> to make the adjustment. To illustrate... I have my player's volume
>> set at
>> 6 and the NVV is 50... the server would adjust the output volume to 3.
>>
>> Ok, I know it is more complicated than I describe, but something to
>> preserve
>> the original source yet tackle the volume issue without burdening the
>> server
>> with resampling would be a very welcome addition.
>
>
> You've pretty much described ReplayGain: http://www.replaygain.org/
>
> There is good support in the FLAC format for ReplayGain and probably
> other formats. There's an RFE open against SlimServer for ReplayGain
> support - attach your email to the bug's interest list to show your
> interest. :)
>
> --Jason
>

Jason Holtzapple
2004-08-17, 08:41
James Craig wrote:
> ...and MP3gain uses the replaygain analysis and does pretty much what is
> described below.
> As I understand it a negative volume gain (or something similar) is
> stored in the mp3 meta data - and as it's part of the MP3 spec it is
> used by all players.

It adjusts the scale factor of the mp3 directly, so most (but still not
all) players will use the new mp3gain'd volume.

> The original gain value is kept in the mp3gain logs (which is the only
> problem I can see) and can be restored
> - as long as you don't lose them.

The latest version saves this information in the mp3 file itself (in an
apev2 tag at the end of the file) so it's rather more convenient than
keeping the log file around.

--Jason

James Craig
2004-08-17, 08:53
That's interesting - what players doesn't it work with?

Looks like i need to download the latest version anyway...

James

Jason Holtzapple wrote:

> James Craig wrote:
>
>> ...and MP3gain uses the replaygain analysis and does pretty much what
>> is described below.
>> As I understand it a negative volume gain (or something similar) is
>> stored in the mp3 meta data - and as it's part of the MP3 spec it is
>> used by all players.
>
>
> It adjusts the scale factor of the mp3 directly, so most (but still not
> all) players will use the new mp3gain'd volume.
>
>> The original gain value is kept in the mp3gain logs (which is the
>> only problem I can see) and can be restored
>> - as long as you don't lose them.
>
>
> The latest version saves this information in the mp3 file itself (in an
> apev2 tag at the end of the file) so it's rather more convenient than
> keeping the log file around.
>
> --Jason
>

Jason Holtzapple
2004-08-17, 09:03
James Craig wrote:
> That's interesting - what players doesn't it work with?

I remember reading about a Kenwood Car CD/mp3 player and an AIWA portable
CD/mp3 player that did not play the mp3gain'd files correctly. I don't
remember the exact models. Personally I've never run across a player that
did not play correctly. If a player does not work it is breaking the mp3
spec in some way.

> Jason Holtzapple wrote:
>
>> James Craig wrote:
>>
>>> ...and MP3gain uses the replaygain analysis and does pretty much what
>>> is described below.
>>> As I understand it a negative volume gain (or something similar) is
>>> stored in the mp3 meta data - and as it's part of the MP3 spec it is
>>> used by all players.
>>
>> It adjusts the scale factor of the mp3 directly, so most (but still not
>> all) players will use the new mp3gain'd volume.

Dave Pilgrim
2004-08-18, 05:31
Jason Holtzapple wrote:

>
> There is good support in the FLAC format for ReplayGain and probably
> other formats. There's an RFE open against SlimServer for ReplayGain
> support - attach your email to the bug's interest list to show your
> interest. :)
>

I am a little confused by this. I for one would like to have the option
of using Replay Gain for playback during those "non-audiophile" moments
such as dinner, and to that end have ripped all of my flacs using the
replay gain switch in the command line. I had believed that RG could
already be switched on in the SB via the convert.conf file and recall
having seen a posting from somebody a while back describing the
appropriate syntax. I have been meaning to dig this out and play with
it myself when I get time. Now however it seems from Jason's post that
RG is not yet implemented and is on the request list for future
improvements.

I would appreciate any clarification of this. Ideally I would like to
have RG switchable via the remote so that I could turn it off for
serious listening without the need to edit the convert.conf file.
Perhaps this is what the request is for?

dp

Jason Holtzapple
2004-08-18, 07:20
Dave Pilgrim wrote:
> Jason Holtzapple wrote:
>
>>
>> There is good support in the FLAC format for ReplayGain and probably
>> other formats. There's an RFE open against SlimServer for ReplayGain
>> support - attach your email to the bug's interest list to show your
>> interest. :)
>>
>
> I am a little confused by this. I for one would like to have the option
> of using Replay Gain for playback during those "non-audiophile" moments
> such as dinner, and to that end have ripped all of my flacs using the
> replay gain switch in the command line. I had believed that RG could
> already be switched on in the SB via the convert.conf file and recall
> having seen a posting from somebody a while back describing the
> appropriate syntax. I have been meaning to dig this out and play with
> it myself when I get time. Now however it seems from Jason's post that
> RG is not yet implemented and is on the request list for future
> improvements.
>
> I would appreciate any clarification of this. Ideally I would like to
> have RG switchable via the remote so that I could turn it off for
> serious listening without the need to edit the convert.conf file.
> Perhaps this is what the request is for?

Yes ... but please add your specific request (remote switching) to
the RFE so it doesn't get lost.

http://bugs.slimdevices.com/show_bug.cgi?id=80

Sorry for the confusion. there is no replaygain support in the slimserver
yet. The FLAC decoder (v1.1.1beta or later) itself can apply replaygain
to its output stream - this is where the alternate convert.conf lines come
in. It's a workaround for now.