PDA

View Full Version : Volume Normalization



Chris Lewis
2004-06-24, 10:25
Dear All,

We use Slimdevices for ambient music in all our hotel public areas. It's
proved to be a real success. We have one development need though, we would
like to be able to normalize the volume output, so that we don't have one
tune being noticeably louder or quiter than another. Currently the only way
to do this is to make sure the tracks are all normalized before playing
using other software.

There is a bug track open regarding this

http://bugs.slimdevices.com/show_bug.cgi?id=205
<http://bugs.slimdevices.com/show_bug.cgi?id=205>

I have looked at an open source project called MP3Gain
http://sourceforge.net/projects/mp3gain/
<http://sourceforge.net/projects/mp3gain/> which actually analyses each
track in a selection in dB before normalising them. It would be great if
something like this could be incorporated into Slimserver. I appreciate this
will not be easy but any help would be very much appreciated.

Cheers!



Chris Lewis MCSE
Group IT Manager - Malmaison Ltd.

Malmaison Hotel
Piccadilly
Manchester
M1 3AQ

D: +44 161 278 1052
T: +44 161 278 1000
F: +44 161 278 1002
M: +44 7980 446907
E: CLewis (AT) Malmaison (DOT) com <mailto:CLewis (AT) Malmaison (DOT) com>

Malmaison Hotels, Bars & Brasseries

Edinburgh, Glasgow, Newcastle, Manchester, Leeds, Birmingham, London
Building Oxford .... Tomorrow the world
Book online at malmaison.com

kdf
2004-06-24, 10:55
Hi Chris,

There is also Replay Gain: http://www.replaygain.org/

Both MP3 Gain and Replay Gain have been discussed here before and are a
desireable feature to have in slimserver.

Development on slimserver is currently confined to bug fixes only until the
release of 5.2. The intent is to produce a long-term stable version for mass
release. After that, there will be more time to focus on feature enhancements
such as the Bug 205 and many others.

-kdf

Quoting Chris Lewis <CLewis (AT) malmaison (DOT) com>:

> Dear All,
>
> We use Slimdevices for ambient music in all our hotel public areas. It's
> proved to be a real success. We have one development need though, we would
> like to be able to normalize the volume output, so that we don't have one
> tune being noticeably louder or quiter than another. Currently the only way
> to do this is to make sure the tracks are all normalized before playing
> using other software.
>
> There is a bug track open regarding this
>
> http://bugs.slimdevices.com/show_bug.cgi?id=205
> <http://bugs.slimdevices.com/show_bug.cgi?id=205>
>
> I have looked at an open source project called MP3Gain
> http://sourceforge.net/projects/mp3gain/
> <http://sourceforge.net/projects/mp3gain/> which actually analyses each
> track in a selection in dB before normalising them. It would be great if
> something like this could be incorporated into Slimserver. I appreciate this
> will not be easy but any help would be very much appreciated.
>
> Cheers!

> Chris Lewis MCSE
> Group IT Manager - Malmaison Ltd.

Roy M. Silvernail
2004-06-24, 11:18
Chris Lewis wrote:

> Dear All,
>
> We use Slimdevices for ambient music in all our hotel public areas.
> It's proved to be a real success. We have one development need though,
> we would like to be able to normalize the volume output, so that we
> don't have one tune being noticeably louder or quiter than another.
> Currently the only way to do this is to make sure the tracks are all
> normalized before playing using other software.

Actually, that's the only way to do it at all. Normalization must
analyze the whole track (or set of tracks, in the case of "album
normalization") to determine the needed adjustment. Not something you
can do while playing the track. Audio compression and limiting could be
done at playback time with no preprocessing, but it's not the same
effect as normalization. Personally, I think compression/limiting makes
music sound like cardboard.

> I have looked at an open source project called MP3Gain
> http://sourceforge.net/projects/mp3gain/ which actually analyses each
> track in a selection in dB before normalising them. It would be great
> if something like this could be incorporated into Slimserver. I
> appreciate this will not be easy but any help would be very much
> appreciated.


MP3gain is a two-pass setup that does the analysis on pass one, writing
the adjustments to a tag. An optional second pass applies the actual
adjustment to the track. Several software players will use the gain tag
to make adjustments at playback, removing the need to alter the source
material. Getting Squeezebox to act on MP3gain tags has been suggested
before. But any normalization will require processing the source
material at least once before playback. This is probably better done
when the source material is first ripped or otherwise introduced to the
collection.

--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"It's just this little chromium switch, here." - TFS
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

Jules Taplin
2004-06-24, 11:50
Well... yes... putting a audio compression stage does indeed affect the
sound of music (bringing that great 'FM Radio' feeling to audio, and
stamping on it's dynamics).

However... surely that's what you want for ambient music? In fact...
normalisation isn't what you want for any piece of music that has a wide
range of volumes, because at the 'background music' volume, quiet patches
will effectively disappear. If you're talking about large areas and quiet
volumes, it sounds to me like exactly the right approach would be a fairly
aggressive compresser/limiter step to bring all the quiet bits up, and stamp
the gain down on the loud bits.

Not exactly true to the original performance, but then that's not the point
for covering large areas, surely.

-- Jules

----- Original Message -----
From: "Roy M. Silvernail" <roy (AT) rant-central (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Thursday, June 24, 2004 7:18 PM
Subject: Re: [Developers] Volume Normalization


> Chris Lewis wrote:
>
> > Dear All,
> >
> > We use Slimdevices for ambient music in all our hotel public areas.
> > It's proved to be a real success. We have one development need though,
> > we would like to be able to normalize the volume output, so that we
> > don't have one tune being noticeably louder or quiter than another.
> > Currently the only way to do this is to make sure the tracks are all
> > normalized before playing using other software.
>
> Actually, that's the only way to do it at all. Normalization must
> analyze the whole track (or set of tracks, in the case of "album
> normalization") to determine the needed adjustment. Not something you
> can do while playing the track. Audio compression and limiting could be
> done at playback time with no preprocessing, but it's not the same
> effect as normalization. Personally, I think compression/limiting makes
> music sound like cardboard.
>
> > I have looked at an open source project called MP3Gain
> > http://sourceforge.net/projects/mp3gain/ which actually analyses each
> > track in a selection in dB before normalising them. It would be great
> > if something like this could be incorporated into Slimserver. I
> > appreciate this will not be easy but any help would be very much
> > appreciated.
>
>
> MP3gain is a two-pass setup that does the analysis on pass one, writing
> the adjustments to a tag. An optional second pass applies the actual
> adjustment to the track. Several software players will use the gain tag
> to make adjustments at playback, removing the need to alter the source
> material. Getting Squeezebox to act on MP3gain tags has been suggested
> before. But any normalization will require processing the source
> material at least once before playback. This is probably better done
> when the source material is first ripped or otherwise introduced to the
> collection.
>
> --
> Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
> "It's just this little chromium switch, here." - TFS
> SpamAssassin->procmail->/dev/null->bliss
> http://www.rant-central.com
>
>

Pat Farrell
2004-06-24, 12:04
At 01:25 PM 6/24/2004, Chris Lewis wrote:
>that we don't have one tune being noticeably louder or quiter than
>another. Currently the only way to do this is to make sure the tracks are
>all normalized before playing using other software.
>
>It would be great if something like this could be incorporated into
>Slimserver. I appreciate this will not be easy but any help would be very
>much appreciated.


I'm just a user, and while I can understand your need, I think it is a
_bad_ thing
to do as part of the SlimServer. For a couple of reasons:

1) it is a one-time task. Once a file is normalized, there is no need to do
it again, ever.
The SlimServer is about doing something to the files over and over and over.
Your suggestion puts the solution in the wrong space.

2) the SlimServer has too much to do already. A lot of effort in recent times
(ie. the 5.2 release) has been addressing performance problems. Adding
cool features always costs performance

3) Normalization is not really what you need. You really want compression.
Normalization makes the peak level even across songs. This is not the same
as making the loudness the same. To get that, you need compression.
Usually one compresses and then raises the makeup gain to get
effective normalization.

Since this is really a library management issue, not a music playing issue,
I think it really belongs in a separate package, such as my Java
library utilities. http://www.pfarrell.com/music/slimsoftware.html

Just IMHO
Pat

Roy M. Silvernail
2004-06-24, 12:12
Jules Taplin wrote:

>Well... yes... putting a audio compression stage does indeed affect the
>sound of music (bringing that great 'FM Radio' feeling to audio, and
>stamping on it's dynamics).
>
>However... surely that's what you want for ambient music?
>
I hadn't thought of that, but you're absolutely right. For wide-area
background music, a compressor/limiter would be perfect.

--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"It's just this little chromium switch, here." - TFS
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

ron thigpen
2004-06-24, 12:43
Roy M. Silvernail wrote:

> I hadn't thought of that, but you're absolutely right. For wide-area
> background music, a compressor/limiter would be perfect.

And one way for slim-server to accomplish this would be through external
processors. Std-in and Std-out through an effects processor.

We're already using a similar scheme for on-the-fly
encode/decode/transcode. In on case, bandwidth limiting, we're doing it
specifically in order to alter a characteristic of the signal.

Analogies for this exist in WinAmp, with it's In, Out and DSP plug-ins,
and in the "effects loop" that is standard on audio mixing boards.

All we'd really need slimwise is the ability to daisy chain IO streams
and some syntax for the config file. Plug-in wise, does anyone know of
a decent, Free commandline audio effects processor? Extra points for
taking advantage of common sound card DSP acceleration.

Now, I'm in perfect agreement that playback is not always the optimal
place to do this, but this would be up to users to configure for and
would provide a lot of flexibity.

--rt

Jake Hawkes
2004-06-24, 13:13
ron thigpen said:
> Plug-in wise, does anyone know of
> a decent, Free commandline audio effects processor?

sox?

Jules Taplin
2004-06-24, 13:19
Hmmm. Sounds like 'sox' is the main game in town for this kind of thing.

It certainly has what looks like a compressor/limiter effect to me, as well
as various other filters. In fact... it'll do resampling, too... and didn't
I see something about external DACs or Digital Speakers not working unless
it's fed the right sample frequency? Might be just the thing.

http://www.spies.com/Sox/

Licensing looks reasonably inoffensive, too: 'SoX may be used for any
purpose. Source distributions must include the copyright notices. Binary
distributions must include acknowledgements to the creators. The files I
wrote are copyright Lance Norskog. The contributed files are copyright by
their respective authors. '


-- Jules

----- Original Message -----
From: "ron thigpen" <ron (AT) fuzzsonic (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Thursday, June 24, 2004 8:43 PM
Subject: Re: [Developers] Volume Normalization


> Roy M. Silvernail wrote:
>
> > I hadn't thought of that, but you're absolutely right. For wide-area
> > background music, a compressor/limiter would be perfect.
>
> And one way for slim-server to accomplish this would be through external
> processors. Std-in and Std-out through an effects processor.
>
> We're already using a similar scheme for on-the-fly
> encode/decode/transcode. In on case, bandwidth limiting, we're doing it
> specifically in order to alter a characteristic of the signal.
>
> Analogies for this exist in WinAmp, with it's In, Out and DSP plug-ins,
> and in the "effects loop" that is standard on audio mixing boards.
>
> All we'd really need slimwise is the ability to daisy chain IO streams
> and some syntax for the config file. Plug-in wise, does anyone know of
> a decent, Free commandline audio effects processor? Extra points for
> taking advantage of common sound card DSP acceleration.
>
> Now, I'm in perfect agreement that playback is not always the optimal
> place to do this, but this would be up to users to configure for and
> would provide a lot of flexibity.
>
> --rt
>
>
>

ron thigpen
2004-06-24, 13:31
Jules Taplin wrote:

> Hmmm. Sounds like 'sox' is the main game in town for this kind of thing.

and the good news is, once slim config is wired up for this sort of
thing, anything that comes along that'll take cmdline switches should be
pretty darn straightforward to integrate.

--rt

Dan Sully
2004-06-24, 14:11
* ron thigpen <ron (AT) fuzzsonic (DOT) com> shaped the electrons to say...

>>Hmmm. Sounds like 'sox' is the main game in town for this kind of thing.
>
>and the good news is, once slim config is wired up for this sort of
>thing, anything that comes along that'll take cmdline switches should be
>pretty darn straightforward to integrate.

More pipes are bad. We already have potential deadlock issues with double piping.

-D
--
"My pockets hurt." -homer

ron thigpen
2004-06-24, 14:18
Dan Sully wrote:

> More pipes are bad. We already have potential deadlock issues with
> double piping.

workarounds? alternatives?

--rt

Dan Sully
2004-06-24, 14:20
* ron thigpen <ron (AT) fuzzsonic (DOT) com> shaped the electrons to say...

>>More pipes are bad. We already have potential deadlock issues with
>>double piping.
>
>workarounds? alternatives?

Don't do that? ;)

Seriously - I'm working on some alternatives. Pre-processing is still the
best way to go right now. For FLAC & Ogg, both can do replay-gain relatively
easily on the fly.

-D
--
"My pockets hurt." -homer

ron thigpen
2004-06-24, 14:33
Dan Sully wrote:

> Seriously - I'm working on some alternatives. Pre-processing is still
> the best way to go right now. For FLAC & Ogg, both can do replay-gain
> relatively easily on the fly.

Yeah, and that's great if it's built in. I was thinking of a more
extensible set up where you might be able to other types of processing:
compression, EQ, reverb, whatever. I can't see these being in the
encoders, it's just not core to what they do.

So, looking for other ways to slot a component like this into the
processing stream.

Different ways to do this with pipes(?):

SS | Decoder | SS | DSP | SS | SB
SS | Decoder | DSP | SS | SB

The second method would only present one (daisy-chained) In/Out set to
the SlimServer. Does this represent an opportunity? Can the external
apps be chained in this way? Seems like Unix is build upon many small
executables chained together in this way.

I'm getting a bit far afield of my tech knowledge here, but if there is
potential here, I want to explore. Ideas welcome.

--rt

Roy M. Silvernail
2004-06-24, 15:31
On Thu, 2004-06-24 at 16:13, Jake Hawkes wrote:
> ron thigpen said:
> > Plug-in wise, does anyone know of
> > a decent, Free commandline audio effects processor?
>
> sox?

Bingo! Here's the list:


Effects:
avg [ -l | -r | -f | -b | n,n,...,n ]
band [ -n ] center [ width ]
bandpass frequency bandwidth
bandreject frequency bandwidth
chorus gain-in gain out delay decay speed depth
-s | -t [ delay decay speed depth -s | -t ]
compand attack1,decay1[,attack2,decay2...]
in-dB1,out-dB1[,in-dB2,out-dB2...]
[ gain [ initial-volume [ delay ] ] ]
copy
dcshift shift [ limitergain ]
deemph
earwax
echo gain-in gain-out delay decay [ delay decay ... ]
echos gain-in gain-out delay decay [ delay decay ... ]
fade [ type ] fade-in-length
[ stop-time [ fade-out-length ] ]
filter [ low ]-[ high ] [ window-len [ beta ]]
flanger gain-in gain-out delay decay speed < -s | -t >
highp frequency
highpass frequency
lowp frequency
lowpass frequency
map
mask
pan direction
phaser gain-in gain-out delay decay speed < -s | -t >
pick [ -1 | -2 | -3 | -4 | -l | -r ]
pitch shift [ width interpole fade ]
polyphase [ -w < nut / ham > ]
[ -width < long / short / # > ]
[ -cutoff # ]
rate
resample [ -qs | -q | -ql ] [ rolloff [ beta ] ]
reverb gain-out reverb-time delay [ delay ... ]
reverse
silence above_periods [ duration threshold[ d | % ]
[ below_periods duration
threshold[ d | % ]]
speed [ -c ] factor
split
stat [ -s n ] [ -rms ] [ -v ] [ -d ]
stretch [ factor [ window fade shift fading ]
swap [ 1 2 | 1 2 3 4 ]
synth [ length ] type mix [ freq [ -freq2 ]
[ off ] [ ph ] [ p1 ] [ p2 ] [ p3 ]
trim start [ length ]
vibro speed [ depth ]
vol gain [ type [ limitergain ] ]

Think that's general-purpose enough?
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"Progress, like reality, is not optional." - R. A. Hettinga
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

Roy M. Silvernail
2004-06-24, 15:47
On Thu, 2004-06-24 at 17:33, ron thigpen wrote:

> So, looking for other ways to slot a component like this into the
> processing stream.
>
> Different ways to do this with pipes(?):
>
> SS | Decoder | SS | DSP | SS | SB
> SS | Decoder | DSP | SS | SB
>
> The second method would only present one (daisy-chained) In/Out set to
> the SlimServer. Does this represent an opportunity? Can the external
> apps be chained in this way? Seems like Unix is build upon many small
> executables chained together in this way.

It's pretty straightforward to read from a pipeline or write to a
pipeline. But doing both is a bit tricky, especially for streaming
content. There's almost no way to avoid forking a separate process to
fill the pipe. Pipeline processing right now depends on the first
program in the pipeline to handle reading from the data source (usually
a disc file).

On top of that, not all programs behave well in pipelines. Some (older
ffmpeg builds, for instance) ignore SIGPIPE and don't shut down when
their input or output goes away, like when you skip to the next track.
The pipelining built into perl hands the whole pipeline off to a spawned
shell process, so it becomes hard to control the children with the shell
in the way. And remember we need to support Windows, where pipelines
are not implemented the same way as on Linux or OS-X. I think
ActiveState perl fakes them along with fork().

Your second construct is almost right, but you have to clip SS off the
front end. Even so, your complexity goes up with every added link in
the chain.

> I'm getting a bit far afield of my tech knowledge here, but if there is
> potential here, I want to explore. Ideas welcome.

Plug-in DSP *is* a good idea. The execution is the tricky part.
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"Progress, like reality, is not optional." - R. A. Hettinga
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com