Menu
▾
▴
sox-users
|
From: Klaus S. <kls...@go...> - 2009-10-11 14:43:13
|
Hi folks. I am not that deep into normalization/mastering/replay gain. So perhaps below problem is a pretty trivial one. I could not bring it all together by reading the SOX man pages. Perhaps somebody can help here. Is there a way I could apply some kind of reference playback level (replay gain) to my tracks (.wav/.flac) so that I can avoid to change my volume control every other song? How would I set/calibrate my "reference level" ? Goal: I would like to end up being able to play all my stuff at a certain reference listening level e.g. 89db (without facing any quality issues due to conversion losses). How can that be done using SOX? THX \Klaus |
|
From: robs <aq...@ya...> - 2009-10-11 18:48:31
|
SoX will honor replain gain tags if they are found in a file that is being played by SoX, but in order to create those tags you need to use a separate replay-gain tool with support for your audio file format. Cheers, Rob --- On Sun, 11/10/09, Klaus Schulz <kls...@go...> wrote: > From: Klaus Schulz <kls...@go...> > Subject: [SoX-users] Normalization/Replaygain - with reference level ? > To: sox...@li... > Date: Sunday, 11 October, 2009, 3:43 PM > Hi folks. > > I am not that deep into normalization/mastering/replay > gain. So perhaps below problem is a pretty trivial one. > I could not bring it all together by reading the SOX man > pages. Perhaps somebody can help here. > > > > Is there a way I could apply some kind of reference > playback level (replay gain) to my tracks (.wav/.flac) > so that I can avoid to change my volume control every other > song? > > How would I set/calibrate my "reference level" > ? > > > Goal: I would like to end up being able to play all my > stuff at a certain reference listening level e.g. 89db > (without facing any quality issues due to conversion > losses). > > How can that be done using SOX? > > > > THX > \Klaus > > > > > -----Inline Attachment Follows----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference > in SF, CA > is the only developer event you need to attend this year. > Jumpstart your > developing skills, take BlackBerry mobile applications to > market and stay > ahead of the curve. Join us from November 9 - 12, 2009. > Register now! > http://p.sf.net/sfu/devconference > -----Inline Attachment Follows----- > > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
|
From: Fmiser <fm...@gm...> - 2009-10-12 02:26:57
|
> robs wrote: > SoX will honor replain gain tags if they are found in a file > that is being played by SoX, but in order to create those tags > you need to use a separate replay-gain tool with support for > your audio file format. This looks like a decent reference on the topic. http://www.bobulous.org.uk/misc/Replay-Gain-in-Linux.html -- Philip |
|
From: Klaus S. <kls...@go...> - 2009-10-12 07:58:17
|
A tagged Replay-Gain is not what I am looking for. As far as I understood from the man-pages, Sox delivers quite some tools to achieve what I am looking for. How about? sox infile outfile gain -n -xdb Could this be the solution if I understand it right? First I bring everything up to a common level and then I can apply a general attenuation to get my e.g. constant 89db listening level. The question is what -n= normalization to 0dbfs does? Would all tracks sound the same in terms of perceived listening level? Is it based on peaks or rms -- can I choose? Do I face any quality losses? What would happen to highly dynamic music such as classical pieces if being normalized? (Clipping protection/need for limiting might impact the sound quality/dynamics) On Mon, Oct 12, 2009 at 4:25 AM, Fmiser <fm...@gm...> wrote: > > robs wrote: > > > SoX will honor replain gain tags if they are found in a file > > that is being played by SoX, but in order to create those tags > > you need to use a separate replay-gain tool with support for > > your audio file format. > > > This looks like a decent reference on the topic. > http://www.bobulous.org.uk/misc/Replay-Gain-in-Linux.html > > -- Philip > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
|
From: Fmiser <fm...@gm...> - 2009-10-12 21:18:59
|
> Klaus Schulz wrote: > A tagged Replay-Gain is not what I am looking for. As far as > I understood from the man-pages, Sox delivers quite some tools > to achieve what I am looking for. Ah-ha! So you want to actually alter the file. Decode, adjust gain, re-encode. Sorry I misunderstood. > How about? > > sox infile outfile gain -n -xdb > > Could this be the solution if I understand it right? First I > bring everything up to a common level and then I can apply a > general attenuation to get my e.g. constant 89db listening > level. What is "89 dB listening level"? I saw reference to 89 dB SPL in the replay-gain docs. Which is silly because the master volume control, amp gain, speaker efficiency, distance to speakers are all beyond the control of the audio file but all will determine the Sound Pressure Level. I gather what you want is a result that is similar to the goal of replay gain but done with changes to the audio portion of the file, not metadata tags. In other words, you want the loud portions of every sound file to sound to your ears like they are the same "volume". How quiet the quieter portions are will still depend on the recording. > The question is what -n= normalization to 0dbfs does? It adjusts the gain so the peak level of the file is the highest level the digital format can represent. (0 dBFS, or 0 dB FullScale). > Would all tracks sound the same in terms of perceived listening > level? No. > Is it based on peaks or rms -- can I choose? No choice. Normalize is based on peak level. What we perceive as "volume" much more closely follows RMS - but not exactly. (a large part of what still doesn't match is due to frequency) > Do I face any quality losses? Not with WAV, flac, or other loss-less formats. Any of the lossy formats will have a "generation" loss because they will be decoded and re-encoded. > What would happen to highly dynamic music such as classical > pieces if being normalized? The dynamic structure is maintained. Normalize is just "turn it up as much as possible without ever clipping". > (Clipping protection/need for limiting might impact the sound > quality/dynamics) If you want to compress the dynamics (change the crest factor), use "compand" - but I don't think that's what you want... The "stats" effect (recent versions) will report the RMS level, the peak level, and crest factor (the difference between them). You could use that data to make the necessary adjustments using sox "gain" effect. Or you could try the linux command line tool "normalize-audio". -- Philip |
|
From: Klaus S. <kls...@go...> - 2009-10-13 07:32:48
|
On Mon, Oct 12, 2009 at 11:17 PM, Fmiser <fm...@gm...> wrote: > > Klaus Schulz wrote: > > > A tagged Replay-Gain is not what I am looking for. As far as > > I understood from the man-pages, Sox delivers quite some tools > > to achieve what I am looking for. > > Ah-ha! So you want to actually alter the file. Decode, adjust > gain, re-encode. Sorry I misunderstood. > > Yep. That's what I am looking for. > > How about? > > > > sox infile outfile gain -n -xdb > > > > Could this be the solution if I understand it right? First I > > bring everything up to a common level and then I can apply a > > general attenuation to get my e.g. constant 89db listening > > level. > > What is "89 dB listening level"? I saw reference to 89 dB > SPL in the replay-gain docs. Which is silly because the master > volume control, amp gain, speaker efficiency, distance to > speakers are all beyond the control of the audio file but all > will determine the Sound Pressure Level. > > db SPL. The sound pressure reaching the ear. Correct. 89db SPL -- it could have been anything else -- it was just an example You are right, considering digital volume control, amp gain, speaker SPL and distance to the ears a certain level and always constant level I would like to generate with Sox. Kind of calibration. > I gather what you want is a result that is similar to the goal > of replay gain but done with changes to the audio portion of > the file, not metadata tags. > > Correct. Not all files will have meta tags, > In other words, you want the loud portions of every sound file > to sound to your ears like they are the same "volume". How > quiet the quieter portions are will still depend on the > recording. > > I am just looking for an automatic volume control ( to build it into my own player), which calibrates everything to my "preferred" listening level, without jeopardizing the sound quality. What I do today : I save my preferred listening volume per album in a file. Every time the player starts I can configure the player that it reads that flag. > > The question is what -n= normalization to 0dbfs does? > > It adjusts the gain so the peak level of the file is the highest > level the digital format can represent. (0 dBFS, or 0 dB FullScale). > > > Would all tracks sound the same in terms of perceived listening > > level? > > No. > > > Is it based on peaks or rms -- can I choose? > > No choice. Normalize is based on peak level. What we perceive > as "volume" much more closely follows RMS - but not > exactly. (a large part of what still doesn't match is due to > frequency) > > So even with RMS I wouldn't achieve my goal 100%. Perhaps in the future there'll be a function which even considers the frequency domain to get an exact match. > > Do I face any quality losses? > > Not with WAV, flac, or other loss-less formats. Any of the lossy > formats will have a "generation" loss because they will be > decoded and re-encoded. > > > What would happen to highly dynamic music such as classical > > pieces if being normalized? > > The dynamic structure is maintained. Normalize is just "turn > it up as much as possible without ever clipping". > > > (Clipping protection/need for limiting might impact the sound > > quality/dynamics) > > If you want to compress the dynamics (change the crest > factor), use "compand" - but I don't think that's what you > want... > > The "stats" effect (recent versions) will report the RMS > level, the peak level, and crest factor (the difference > between them). You could use that data to make the necessary > adjustments using sox "gain" effect. > > I'll have a look at the stats. Or you could try the linux command line tool > "normalize-audio". > > -- Philip > > Thanks Klaus > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
|
From: Klaus S. <kls...@go...> - 2009-10-13 14:53:54
|
Hi. I just extracted two RMS values: 1 from normal CD (old style recoding levels) and 2nd one from XRCD -- both instrumental music Normal recording: Samples read: 21877128 Length (seconds): 248.040000 Scaled by: 2147483647.0 Maximum amplitude: 0.937500 Minimum amplitude: -0.929352 Midline amplitude: 0.004074 Mean norm: 0.049860 Mean amplitude: -0.000037 RMS amplitude: 0.081711 (0.088... on a second song) Maximum delta: 0.833069 Minimum delta: 0.000000 Mean delta: 0.034745 RMS delta: 0.060981 Rough frequency: 5238 Volume adjustment: 1.067 XRCD: Samples read: 23196600 Length (seconds): 263.000000 Scaled by: 2147483647.0 Maximum amplitude: 0.943054 Minimum amplitude: -0.943085 Midline amplitude: -0.000015 Mean norm: 0.170348 Mean amplitude: 0.000013 RMS amplitude: 0.224980 Maximum delta: 0.948212 Minimum delta: 0.000000 Mean delta: 0.103665 RMS delta: 0.136676 Rough frequency: 4263 Volume adjustment: 1.060 As you can see the RMS is substantially higher on the XRCD. The peak though is pretty similar. How do I calculate the required gain to adjust the level? This way- I guess: gain-delta = 20log (Amplitude 2/ Amplitude 1) = 20log(0.224980/0.081711) =8,79db In above example this would be a delta of 8,79 db (from my listening experience this doesn't seem to be that wrong) Now - my reference track ( the first one) is running at a sox gain of -6db to achieve the wanted listening level. To achieve the same listening volume with the 2nd track I have to run the 2nd track at a gain of -6db-8,79db=-14,8db How do I practically implement that function: I guess I'd take my reference amplitude and gain, run a "sox stat", extract the RMS value for the new track and do the math. Not too difficult. Too complicated? Hmmh. Something like this calculation would be a nice new feature for sox. Also: Ever thought of a "soxi -rms"? Two more questions: Why do I have to give a dummy output file to the stat option? Are there any plans to make Sox work in double precision throughout? An option would be nice where I could choose (single/double) precision dsp. Thanks \Klaus On Tue, Oct 13, 2009 at 9:32 AM, Klaus Schulz <kls...@go...>wrote: > > > On Mon, Oct 12, 2009 at 11:17 PM, Fmiser <fm...@gm...> wrote: > >> > Klaus Schulz wrote: >> >> > A tagged Replay-Gain is not what I am looking for. As far as >> > I understood from the man-pages, Sox delivers quite some tools >> > to achieve what I am looking for. >> >> Ah-ha! So you want to actually alter the file. Decode, adjust >> gain, re-encode. Sorry I misunderstood. >> >> > Yep. That's what I am looking for. > > > >> > How about? >> > >> > sox infile outfile gain -n -xdb >> > >> > Could this be the solution if I understand it right? First I >> > bring everything up to a common level and then I can apply a >> > general attenuation to get my e.g. constant 89db listening >> > level. >> >> What is "89 dB listening level"? I saw reference to 89 dB >> SPL in the replay-gain docs. Which is silly because the master >> volume control, amp gain, speaker efficiency, distance to >> speakers are all beyond the control of the audio file but all >> will determine the Sound Pressure Level. >> >> > db SPL. The sound pressure reaching the ear. Correct. > > 89db SPL -- it could have been anything else -- it was just an example > > You are right, considering digital volume control, amp gain, speaker SPL > and distance to the ears a certain level and always constant level I would > like to generate with Sox. Kind of calibration. > > > > >> I gather what you want is a result that is similar to the goal >> of replay gain but done with changes to the audio portion of >> the file, not metadata tags. >> >> > Correct. Not all files will have meta tags, > > > >> In other words, you want the loud portions of every sound file >> to sound to your ears like they are the same "volume". How >> quiet the quieter portions are will still depend on the >> recording. >> >> > I am just looking for an automatic volume control ( to build it into my own > player), which calibrates everything to my "preferred" listening level, > without > jeopardizing the sound quality. What I do today : I save my preferred > listening volume per album in a file. Every time the player starts I can > configure the player that it reads that flag. > > > >> > The question is what -n= normalization to 0dbfs does? >> >> It adjusts the gain so the peak level of the file is the highest >> level the digital format can represent. (0 dBFS, or 0 dB FullScale). >> >> > Would all tracks sound the same in terms of perceived listening >> > level? >> >> No. >> >> > Is it based on peaks or rms -- can I choose? >> >> No choice. Normalize is based on peak level. What we perceive >> as "volume" much more closely follows RMS - but not >> exactly. (a large part of what still doesn't match is due to >> frequency) >> >> > So even with RMS I wouldn't achieve my goal 100%. Perhaps in the future > there'll be a function which > even considers the frequency domain to get an exact match. > > > >> > Do I face any quality losses? >> >> Not with WAV, flac, or other loss-less formats. Any of the lossy >> formats will have a "generation" loss because they will be >> decoded and re-encoded. >> >> > What would happen to highly dynamic music such as classical >> > pieces if being normalized? >> >> The dynamic structure is maintained. Normalize is just "turn >> it up as much as possible without ever clipping". >> >> > (Clipping protection/need for limiting might impact the sound >> > quality/dynamics) >> >> If you want to compress the dynamics (change the crest >> factor), use "compand" - but I don't think that's what you >> want... >> >> The "stats" effect (recent versions) will report the RMS >> level, the peak level, and crest factor (the difference >> between them). You could use that data to make the necessary >> adjustments using sox "gain" effect. >> >> > I'll have a look at the stats. > > Or you could try the linux command line tool >> "normalize-audio". >> >> -- Philip >> >> > > > Thanks Klaus > > > > >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Sox-users mailing list >> Sox...@li... >> https://lists.sourceforge.net/lists/listinfo/sox-users >> > > |
|
From: robs <aq...@ya...> - 2009-10-13 19:29:50
|
--- On Tue, 13/10/09, Klaus Schulz <kls...@go...> wrote:
...
> Two more questions:
>
> Why do I have to give a dummy output file to the stat
> option?
The sox command always operates as an audio processing chain with an input and an output, but if you don't actually require an audio output, just specify -n (meaning null).
> Are there any plans to make Sox work in double precision
> throughout? An option would be nice where I could choose
> (single/double) precision dsp.
As far as we know, SoX's current accuracy is sufficient even for professional applications, but do you think otherwise?
Cheers,
Rob
|
|
From: Klaus S. <kls...@go...> - 2009-10-14 09:28:50
|
Hi Rob. On Tue, Oct 13, 2009 at 9:29 PM, robs <aq...@ya...> wrote: > --- On Tue, 13/10/09, Klaus Schulz <kls...@go...> wrote: > > ... > > > Two more questions: > > > > Why do I have to give a dummy output file to the stat > > option? > > The sox command always operates as an audio processing chain with an input > and an output, but if you don't actually require an audio output, just > specify -n (meaning null). > > THX. Must have overseen it. > > Are there any plans to make Sox work in double precision > > throughout? An option would be nice where I could choose > > (single/double) precision dsp. > > As far as we know, SoX's current accuracy is sufficient even for > professional applications, but do you think otherwise? > > Working with brutefir shows audible benefits if working with double precision. That's not only me saying that. I think it is obvious that the accuracy should increase. Talking about performance: If you do offline processing doubles shouldn't be an issue. Realtime processing might be too much. Implementation: As it is done in brutefir: you just choose double/single processing in the basic config. Is it much more complicated then implementing some declarations and to implement a startup option? ( I know -- pretty naive way of looking at things) > Cheers, > Rob > > > Cheers Klaus > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
|
From: Michael C. <ch...@mc...> - 2009-10-14 14:31:12
|
On Wednesday 14 October 2009 9:28 am, you wrote: > > > Are there any plans to make Sox work in double precision > > > throughout? An option would be nice where I could choose > > > (single/double) precision dsp. > > > > As far as we know, SoX's current accuracy is sufficient even for > > professional applications, but do you think otherwise? > > Working with brutefir shows audible benefits if working with double > precision. That's not only me saying that. Have you a reference for that? > I think it is obvious > that the accuracy should increase. > > Talking about performance: If you do offline processing doubles shouldn't > be an issue. Realtime processing might be too much. > Implementation: As it is done in brutefir: you just choose double/single > processing in the basic config. > > Is it much more complicated then implementing some declarations and to > implement a startup option? ( I know -- pretty naive way of looking at > things) The naïve assessment is that no-one can hear any difference after 16-bits. Going more than 16 has some advantages: -it avoids the rigmarole of dithering -it allows 'headroom' for recording (i.e. you can leave some room in case the orchestra gets more carried away in concert than in the rehearsal ... or if you had no rehearsal and just have to guess a pre-amp gain for the recording). -more esoterically you can use audio-type files for non-audio (e.g. decomposing global ocean levels over time into spherical harmonics) but even then 32-bits is getting pretty precise ... for most things. Still if we have 196 KHz ... and ... computer sales seem in the doldrums ... then ... Michael |
|
From: Pascal G. <evi...@gm...> - 2009-10-14 17:42:32
|
On Wed, Oct 14, 2009 at 7:13 AM, Michael Chapman <ch...@mc...> wrote: > The naïve assessment is that no-one can hear any difference after 16-bits. Please forgive me if i'm off-topic and beware, this is a naïve electrical engineer comment, but... aren't the best ADC only giving an efficient 12bits or so? (Even if then claim 16, iirc, in the lab, i've only measured 12bits). -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) LACIME: École de technologie supérieure (http://lacime.etsmtl.ca) |
|
From: robs <aq...@ya...> - 2009-10-15 15:54:26
|
I think the best ones in PC audio interfaces are good for 19 or maybe 20 bits, but many "24 bit" cards are good for only 17 or 18. /Rob --- On Wed, 14/10/09, Pascal Giard <evi...@gm...> wrote: > Please forgive me if i'm off-topic and beware, this is a > naïve > electrical engineer comment, but... aren't the best ADC > only giving an > efficient 12bits or so? (Even if then claim 16, iirc, in > the lab, i've > only measured 12bits). > > -Pascal > -- > Homepage (http://organact.mine.nu) > Debian GNU/Linux (http://www.debian.org) > LACIME: École de technologie supérieure (http://lacime.etsmtl.ca) > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference > in SF, CA > is the only developer event you need to attend this year. > Jumpstart your > developing skills, take BlackBerry mobile applications to > market and stay > ahead of the curve. Join us from November 9 - 12, 2009. > Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
|
From: Pascal G. <evi...@gm...> - 2009-10-15 18:53:25
|
On Thu, Oct 15, 2009 at 11:54 AM, robs <aq...@ya...> wrote: > I think the best ones in PC audio interfaces are good for 19 or maybe 20 bits, but many "24 bit" cards are good for only 17 or 18. > > /Rob Indeed, that seems to make sense. Looking at the ADCs TI are selling (made Burr-Brown), there are 124dB SNR ADCs (roughly 20.5 bits)... Which makes me realized that things have changed significantly since the last time i checked... -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) LACIME: École de technologie supérieure (http://lacime.etsmtl.ca) |
|
From: Fmiser <fm...@gm...> - 2009-10-14 02:39:44
|
> Klaus Schulz wrote:
> I just extracted two RMS values:
>
> 1 from normal CD (old style recoding levels) and 2nd one from
> XRCD -- both instrumental music
>
> Normal recording:
>
> Maximum amplitude: 0.937500
> RMS amplitude: 0.081711 (0.088... on a second song)
> XRCD:
>
> Maximum amplitude: 0.943054
> RMS amplitude: 0.224980
>
> As you can see the RMS is substantially higher on the XRCD.
> The peak though is pretty similar.
The difference between RMS and peak is "crest factor" and is
_highly_ variable based on content. Symphonic music can have a
crest factor of 20, speech about 12-15, rock music about 11,
dance/hip-hop as little as 8, speaker tests 6, and a
sin wave 3.
You may have more accurate correlation between perceived
"volume" and RMS if you filter before the RMS calculation. I'd
start with something like a 6 dB/octave high-pass at about 150
Hz and a low pass at about 6 kHz.
sox in.file -n highpass -1 150 lowpass -1 6k stats
> How do I calculate the required gain to adjust the level?
>
> This way- I guess: gain-delta = 20log (Amplitude 2/ Amplitude
> 1) = 20log(0.224980/0.081711) =8,79db
That's correct.
> In above example this would be a delta of 8,79 db (from my
> listening experience this doesn't seem to be that wrong)
>
> Now - my reference track ( the first one) is running at a sox
> gain of -6db to achieve the wanted listening level.
> To achieve the same listening volume with the 2nd track I have
> to run the 2nd track at a gain of -6db-8,79db=-14,8db
>
> How do I practically implement that function: I guess I'd
> take my reference amplitude and gain, run a "sox stat",
> extract the RMS value for the new track and do the math. Not
> too difficult. Too complicated? Hmmh.
Since I heavily use command line in Linux, I'd use a bash
script. SoX stat effect piped to grep piped to cut to extract
the RMS value. bc to do the math. SoX gain effect to make the
change.
Since bc only has a natural log function, I used
log10(n) = ln(n)/ln(10)
to mimic log base ten
rmsref=0.081711 # from your reference file
refdif=-6 # the change you need to apply to the reference file
rms=$(sox in.file -n stat 2>&1 | grep "RMS.* amplitude" | cut -d ":" -f 2)
GainFactor=$(echo "scale=3;(l($rmsref/$rms)/l(10))*20+$refdif" | bc -l)
### note: there is only a single "one" (10) in the above,
### the rest are the letter L, lower case.
sox gain $GainFactor in.file out.file
In the version I'm using (14.3.0), "stats" returns the RMS value
in dBFS, so the log function is already done.
The effect "stat" still uses decimal with 1 (one) = 0 dBFS.
If you can run normalize-audio, I'd suggest taking a look at
it. By default it uses RMS and you can specify the target
level.
Could be as easy as:
normalize-audio -a 0.081 in.file
-- Philip
|
|
From: Klaus S. <kls...@go...> - 2009-10-14 09:18:49
|
Hi Philip. You made my day. You may have more accurate correlation between perceived > "volume" and RMS if you filter before the RMS calculation. I'd > start with something like a 6 dB/octave high-pass at about 150 > Hz and a low pass at about 6 kHz. > > sox in.file -n highpass -1 150 lowpass -1 6k stats > > I'll try that one. > > > Since bc only has a natural log function, I used > log10(n) = ln(n)/ln(10) > to mimic log base ten > > I was trying to figure out how to solve this log10 under bash all afternoon yesterday. It is not happening very often that Google won't come up with an answer. Now that I see your solution, it dawns on me that I've seen that conversion before - at school - quite some years back. I actually ended up yesterday by fiddling around with a Python script. Which did actually what I asked for. I am not that deep into Python. However, your solution is the one I'll go for. THX > > rmsref=0.081711 # from your reference file > refdif=-6 # the change you need to apply to the reference file > rms=$(sox in.file -n stat 2>&1 | grep "RMS.* amplitude" | cut -d ":" -f 2) > GainFactor=$(echo "scale=3;(l($rmsref/$rms)/l(10))*20+$refdif" | bc -l) > ### note: there is only a single "one" (10) in the above, > ### the rest are the letter L, lower case. > sox gain $GainFactor in.file out.file > > Thx to present this on a silver plate. ;) > In the version I'm using (14.3.0), "stats" returns the RMS value > in dBFS, so the log function is already done. > > The effect "stat" still uses decimal with 1 (one) = 0 dBFS. > > If you can run normalize-audio, I'd suggest taking a look at > it. By default it uses RMS and you can specify the target > level. > > Could be as easy as: > normalize-audio -a 0.081 in.file > > Hmmh. I'll check it out. Though I have the feeling that I have better control by applying the above approach. > -- Philip > > Again THX a lot. Times of readjusting volume every other track is over now - even without meta tags! This is IMO a really valuable feature. Cheers \Klaus > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
|
From: Klaus S. <kls...@go...> - 2009-10-19 10:31:44
|
Hi Philip. I did some more testing ( wrote a script to do some analysis): trackreference: rms:0.081711 sox-gain:-6db to achieve 92db SPL filter: hp:150 lp:6k album: Carol_Elliott-The_People_I_Meet-1996 ----------------------------------------- tr:01 ga:-8.200 ga-fil:-5.400 delta-ga-fil/nonfil=-2.800db sox-gain(abs)=-14.200db tr:02 ga:-4.440 ga-fil:-1.460 delta-ga-fil/nonfil=-2.980db sox-gain(abs)=-10.440db tr:03 ga:-5.640 ga-fil:-3.940 delta-ga-fil/nonfil=-1.700db sox-gain(abs)=-11.640db tr:04 ga:-8.420 ga-fil:-5.760 delta-ga-fil/nonfil=-2.660db sox-gain(abs)=-14.420db tr:05 ga:-6.060 ga-fil:-4.160 delta-ga-fil/nonfil=-1.900db sox-gain(abs)=-12.060db tr:06 ga:-6.460 ga-fil:-4.180 delta-ga-fil/nonfil=-2.280db sox-gain(abs)=-12.460db tr:07 ga:-5.900 ga-fil:-4.880 delta-ga-fil/nonfil=-1.020db sox-gain(abs)=-11.900db tr:08 ga:-7.820 ga-fil:-6.020 delta-ga-fil/nonfil=-1.800db sox-gain(abs)=-13.820db tr:09 ga:-1.980 ga-fil:-1.520 delta-ga-fil/nonfil=-.460db sox-gain(abs)=-7.980db tr:10 ga:-8.560 ga-fil:-5.460 delta-ga-fil/nonfil=-3.100db sox-gain(abs)=-14.560db tr:11 ga:-8.100 ga-fil:-5.560 delta-ga-fil/nonfil=-2.540db sox-gain(abs)=-14.100db ga= gain difference to reference ga-fil=gain difference after running the file over proposed lp/hp filters Note: This album needs to be considered pretty homogeneous. There are others with much higher differences. Obviously the problem seems to be to find a common denominator of an album. If you look at above my guess would be that something of -5db should do as a kind of average ( If I take out the breakouts) . Of course this is a pretty vague assumption and valid only for this album. Conclusion the discussed approach doesn't seem to work properly for my purpose. Do you have any other ideas? > rmsref=0.081711 # from your reference file > refdif=-6 # the change you need to apply to the reference file > rms=$(sox in.file -n stat 2>&1 | grep "RMS.* amplitude" | cut -d ":" -f 2) > GainFactor=$(echo "scale=3;(l($rmsref/$rms)/l(10))*20+$refdif" | bc -l) > ### note: there is only a single "one" (10) in the above, > ### the rest are the letter L, lower case. > sox gain $GainFactor in.file out.file > > Slight corrections to the above formulars -- below should work: rms=$( sox $z -n stat 2>&1 | grep "RMS.* amplitude" | sed "s/ //g" | cut -d ":" -f 2 ) rms_filter=$( sox $z -n highpass -1 $HP lowpass -1 $LP stat 2>&1 | grep "RMS.* amplitude" | sed "s/ //g" | cut -d ":" -f 2 ) gain=$( echo "scale=3;((((l($rmsref/$rms))/(l(10)))*20)+($refdif))" | bc -l ) Cheers |
|
From: Fmiser <fm...@gm...> - 2009-11-09 22:06:28
|
> Klaus Schulz wrote: > Hi Philip. Sorry for the slow response. Work load, out of town trips, etc have me way behind on my email lists.... > I did some more testing ( wrote a script to do some analysis): > Note: This album needs to be considered pretty homogeneous. > There are others with much higher differences. > > Obviously the problem seems to be to find a common > denominator of an album. If you look at above my guess would be > that something of -5db should do as a kind of average ( If I > take out the breakouts) . Of course this is a pretty > vague assumption and valid only for this album. > > Conclusion the discussed approach doesn't seem to work > properly for my purpose. > > Do you have any other ideas? Are you wanting "album gain" - that is, a value to apply to the each of the files in a collection retaining the relative volume between them? Or do you want each individual file adjusted to be the same volume as all the rest. > > rmsref=0.081711 # from your reference file > > refdif=-6 # the change you need to apply to the reference > > file rms=$(sox in.file -n stat 2>&1 | grep "RMS.* amplitude" > > | cut -d ":" -f 2) GainFactor=$(echo "scale=3;(l > > | ($rmsref/$rms)/l(10))*20+$refdif" | bc -l) > > ### note: there is only a single "one" (10) in the > > ### above, the rest are the letter L, lower case. > > sox gain $GainFactor in.file out.file > > > > > Slight corrections to the above formulars -- below should work: > > rms=$( sox $z -n stat 2>&1 | grep "RMS.* amplitude" | sed > "s/ //g" | cut -d ":" -f 2 ) > rms_filter=$( sox $z -n highpass -1 $HP lowpass -1 $LP stat > 2>&1 | grep "RMS.* amplitude" | sed "s/ //g" | cut -d ":" -f > 2>2 ) > gain=$( echo "scale=3;((((l($rmsref/$rms))/(l(10)))*20) > +($refdif))" | bc -l ) Thanks for the corrections. I had copy/pasted parts and pieces from various places. |
|
From: Fmiser <fm...@gm...> - 2009-11-09 22:06:22
|
> Klaus Schulz wrote: > Hi Philip. Sorry for the slow response. Work load, out of town trips, etc have me way behind on my email lists.... > I did some more testing ( wrote a script to do some analysis): > Note: This album needs to be considered pretty homogeneous. > There are others with much higher differences. > > Obviously the problem seems to be to find a common > denominator of an album. If you look at above my guess would be > that something of -5db should do as a kind of average ( If I > take out the breakouts) . Of course this is a pretty > vague assumption and valid only for this album. > > Conclusion the discussed approach doesn't seem to work > properly for my purpose. > > Do you have any other ideas? Are you wanting "album gain" - that is, a value to apply to the each of the files in a collection retaining the relative volume between them? Or do you want each individual file adjusted to be the same volume as all the rest. In the end, I'd say what matters is not the numbers from the script but "how does it sound?". After treatment, do they sound like they have a similar volume? I'm not sure how replay-gain or normalize-audio calculates "album gain". After couple seconds of thought, I think I would use the value of the one with the highest level to adjust the rest. What all this ignores is - what about the song that 9/10 is quiet with one loud passage. Again I have no idea how other tool deal with this. > Slight corrections to the above formulars -- below should work: > > rms=$( sox $z -n stat 2>&1 | grep "RMS.* amplitude" | sed > "s/ //g" | cut -d ":" -f 2 ) > rms_filter=$( sox $z -n highpass -1 $HP lowpass -1 $LP stat > 2>&1 | grep "RMS.* amplitude" | sed "s/ //g" | cut -d ":" -f > 2>2 ) > gain=$( echo "scale=3;((((l($rmsref/$rms))/(l(10)))*20) > +($refdif))" | bc -l ) Thanks for the corrections. *smile* Add it to my script snippets file. -- Philip |
|
From: Doug C. <idi...@us...> - 2009-11-10 01:05:17
|
> > > Slight corrections to the above formulars -- below should work: > > > > rms=$( sox $z -n stat 2>&1 | grep "RMS.* amplitude" | sed > > "s/ //g" | cut -d ":" -f 2 ) > > rms_filter=$( sox $z -n highpass -1 $HP lowpass -1 $LP stat > > 2>&1 | grep "RMS.* amplitude" | sed "s/ //g" | cut -d ":" -f > > 2>2 ) > > gain=$( echo "scale=3;((((l($rmsref/$rms))/(l(10)))*20) > > +($refdif))" | bc -l ) > > Thanks for the corrections. *smile* Add it to my script snippets > file. > Over this Thanksgiving holiday, I may try to add some support for automatically calculating this kind of thing to the Normalize effect. Suggestions on how this should work (RMS? peak? min(RMS, peak)?) and/or what the command-line syntax should look like would be appreciated. |
|
From: Fmiser <fm...@gm...> - 2009-11-10 07:54:47
|
> Doug Cook wrote: > Over this Thanksgiving holiday, I may try to add some support > for automatically calculating this kind of thing to the > Normalize effect. Suggestions on how this should work (RMS? > peak? min(RMS, peak)?) and/or what the command-line syntax > should look like would be appreciated. > I found this document. http://replaygain.hydrogenaudio.org/calculating_rg.html I think it would be pretty cool to have "replay gain" calculation within sox. -- Philip |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X