25 Jul
2013
25 Jul
'13
8:21 p.m.
Does anybody know why wav files that do not have clipping would clip
when encoding them with lame?
I have a bunch of self-made clips that for various reasons don't have
enough gain. I wrote a wav->wav conversion that determines maximum
gain (as in highest or lowest absolute value) and uses sox' volume
argument to boost. Inspecting it with same gain tools and listening
to it shows the expected gain raise, but not clipping.
Then, when encoding in lame it gets clipped. Lame warns about it and
the values have been boosted to the max. When doing the boost, with
the same factor, directly in lame (feeding in the unboosted wav) I get
the same problem. Very roughly a clip with 3% headroom ends up being
too high by 16%, or about a 20% boost.
What's going on? I assume there is something about mp3 encoding I
don't quite understand.
Is there anything more efficient that I can do about that doing one
lame run to get an appropriate boost value and then doing another
encoding pass?
Here are the stats of a boosted wav file and the resulting lame:
t02c02.tmp.wav_maxgain_tmp.wav:
Samples read: 36900960
Length (seconds): 384.385000
Scaled by: 2147483647.0
Maximum amplitude: 0.969208
Minimum amplitude: -0.970673
Midline amplitude: -0.000732
Mean norm: 0.213396
Mean amplitude: 0.000000
RMS amplitude: 0.274775
Maximum delta: 1.675323
Minimum delta: 0.000000
Mean delta: 0.193639
RMS delta: 0.245325
Rough frequency: 6820
Volume adjustment: 1.030
mp3:
Samples read: 36907776
Length (seconds): 384.456000
Scaled by: 2147483647.0
Maximum amplitude: 1.000000
Minimum amplitude: -1.000000
Midline amplitude: -0.000000
Mean norm: 0.203464
Mean amplitude: 0.000010
RMS amplitude: 0.262007
Maximum delta: 1.636044
Minimum delta: 0.000000
Mean delta: 0.185782
RMS delta: 0.235408
Rough frequency: 6863
Volume adjustment: 1.000
/opt/good-sox/bin/sox WARN sox: `-' input clipped 725 samples
/opt/good-sox/bin/sox WARN sox: `/tmp/cracauer/l.wav' output clipped
360 samples; decrease volume?
Encoding output:
lame -h -b 160 --replaygain-accurate --clipdetect t02c02.tmp.wav_maxgain_tmp.wav
t02c02.tmp.wav_maxgain_tmp.mp3_tmp '&&' mv
t02c02.tmp.wav_maxgain_tmp.mp3_tmp t02c02.tmp.wav_maxgain_tmp.mp3
+ sh
LAME version 3.96.1 (http://lame.sourceforge.net/)
Using polyphase lowpass filter, transition band: 18000 Hz - 18581 Hz
Encoding t02c02.tmp.wav_maxgain_tmp.wav to t02c02.tmp.wav_maxgain_tmp.mp3_tmp
Encoding as 48 kHz 160 kbps j-stereo MPEG-1 Layer III (9.6x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
16015/16018 (100%)| 0:22/ 0:22| 0:22/ 0:22| 17.121x| 0:00
average: 160.0 kbps LR: 2551 (15.93%) MS: 13467 (84.07%)
Writing LAME Tag...done
ReplayGain: -9.1dB
WARNING: clipping occurs at the current gain. Set your decoder to decrease
the gain by at least 1.3dB or encode again using --scale <arg>
(For a suggestion on the optimal value of <arg> encode
with --scale 1 first)
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/
25 Jul
25 Jul
9:40 p.m.
On Thu, Jul 25, 2013 at 02:21:50PM -0400, Martin Cracauer wrote:
Does anybody know why wav files that do not have
clipping would clip
when encoding them with lame?
Because the peak sample value says nothing about the real
level. Take a square wave with peak values +/-1. It is the
sum of a number of sine waves, with frequencies 1,3,5,7,...
times the frequency of the square wave. The first one has
a peak value of about +/-1.27, that is +2 dB. So any encoding
that looks at the spectrum (and mp3 does) will see a level
that is +2 dB.
If you really want to normalise on the peak level, use a
lower one. If you want all your samples to have the same
loudness, use RMS instead of peak, or a real loudness
measurement such as provided by ebumeter.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:14 p.m.
Fons Adriaensen wrote on Thu, Jul 25, 2013 at 07:40:53PM +0000:
On Thu, Jul 25, 2013 at 02:21:50PM -0400, Martin
Cracauer wrote:
Ah. Makes sense. Thanks so much!
Is there a rule of thumb how many db less I should give music to avoid
this? What would be the value for pink noise starting at 40 Hz?
Does anybody know why wav files that do not have
clipping would clip
when encoding them with lame?
Because the peak sample value says nothing about the real
level. Take a square wave with peak values +/-1. It is the
sum of a number of sine waves, with frequencies 1,3,5,7,...
times the frequency of the square wave. The first one has
a peak value of about +/-1.27, that is +2 dB. So any encoding
that looks at the spectrum (and mp3 does) will see a level
that is +2 dB. If you really want to normalise on the peak level, use
a
lower one. If you want all your samples to have the same
loudness, use RMS instead of peak, or a real loudness
measurement such as provided by ebumeter.
Is there a way to hook up ebumeter to just an audio file or a stream
not associated with real time? It seems to come in a jack package only.
Thanks again
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/
10:45 p.m.
Martin Cracauer <cracauer(a)cons.org> a écrit :
Is there a way to hook up ebumeter to just an audio
file or a stream
not associated with real time? It seems to come in a jack package
only.
Thanks again
Martin
http://r128gain.sourceforge.net/
--
Marc
27 Jul
27 Jul
12:35 a.m.
Thanks again. Things are looking much better now. I embraced the
concept of not being able to predict this. Turns out I have old
screwed up things that really benefitted from revisiting them and
cleaning them up.
Marc Lavall??e wrote on Thu, Jul 25, 2013 at 04:45:48PM -0400:
Martin Cracauer <cracauer(a)cons.org> a ??crit :
That works. Comes in the Debian ebumeter package, BTW.
But how do I translate the output to a required db or ratio
adjustment?
I have a file in front of me that was maxed out amplitude wise by
somebody else. According to lame I needed --scale 0.64 to get it not
to clip in lame (should be 3.9 db). Which, BTW was not the value it
first estimated that I would need.
ebur128 --lufs:
Integrated loudness: -4.9 LUFS
Loudness range: 5.5 LU
Integrated threshold: -13.0 LUFS
Range threshold: -25.0 LUFS
Range min: -8.6 LUFS
Range max: -3.1 LUFS
Momentary max: -1.2 LUFS
Short term max: -2.4 LUFS
I don't see that any of the value correspond with what lame needed to
not clip over a collection of different loudness clips. (means: some
clips that needed less --scale have higher numbers here and others
have lower)
I assume the ebumeter output is more for making things sound even
(between different pieces) and not directly a tool to max out
anything, is that right?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/
Is there a way to hook up ebumeter to just an
audio file or a stream
not associated with real time? It seems to come in a jack package
only.
Thanks again
Martin
http://r128gain.sourceforge.net/ 
9:10 a.m.
On Fri, 26 Jul 2013 18:35:02 -0400
Martin Cracauer <cracauer(a)cons.org> wrote:
Thanks again. Things are looking much better now. I
embraced the
concept of not being able to predict this. Turns out I have old
screwed up things that really benefitted from revisiting them and
cleaning them up.
Marc Lavall??e wrote on Thu, Jul 25, 2013 at 04:45:48PM -0400:
A good place to find out about this is the talk by Fons and Jörn given
at the LAC 2011, here's the link to the program page where you can find
the paper, slides and the video recording:
http://lac.linuxaudio.org/2011/?page=program&mode=list
Regards,
Philipp
Martin Cracauer <cracauer(a)cons.org> a
??crit :
That works. Comes in the Debian ebumeter package, BTW.
But how do I translate the output to a required db or ratio
adjustment?
I have a file in front of me that was maxed out amplitude wise by
somebody else. According to lame I needed --scale 0.64 to get it not
to clip in lame (should be 3.9 db). Which, BTW was not the value it
first estimated that I would need.
ebur128 --lufs:
Integrated loudness: -4.9 LUFS
Loudness range: 5.5 LU
Integrated threshold: -13.0 LUFS
Range threshold: -25.0 LUFS
Range min: -8.6 LUFS
Range max: -3.1 LUFS
Momentary max: -1.2 LUFS
Short term max: -2.4 LUFS
I don't see that any of the value correspond with what lame needed to
not clip over a collection of different loudness clips. (means: some
clips that needed less --scale have higher numbers here and others
have lower)
I assume the ebumeter output is more for making things sound even
(between different pieces) and not directly a tool to max out
anything, is that right?
Martin Is there a way to hook up ebumeter to just an
audio file or a
stream not associated with real time? It seems to come in a jack
package only.
Thanks again
Martin
http://r128gain.sourceforge.net/
11:17 a.m.
On Fri, Jul 26, 2013 at 06:35:02PM -0400, Martin Cracauer wrote:
ebur128 --lufs:
Integrated loudness: -4.9 LUFS
Loudness range: 5.5 LU
Integrated threshold: -13.0 LUFS
Range threshold: -25.0 LUFS
Range min: -8.6 LUFS
Range max: -3.1 LUFS
Momentary max: -1.2 LUFS
Short term max: -2.4 LUFS
This seems to be in the 'braindead' category...
I don't see that any of the value correspond with
what lame needed to
not clip over a collection of different loudness clips. (means: some
clips that needed less --scale have higher numbers here and others
have lower)
You can't expect that. Lame's limit are specific for the algorithm
it uses. That would be the case for any lossy encoding system.
I assume the ebumeter output is more for making things
sound even
(between different pieces) and not directly a tool to max out
anything, is that right?
That is absolutely right. Systems such as EBU-R128 exist because
it makes perfect sense to make things sound even (avoiding your
listeners having to adjust the volume all the time), while 'maxing
out' serves no useful purpose at all - it just destroys the sound
if taken too far. In other words, such systems exist to *stop* you
'maxing out' everything.
Lame's 'replaygain' meausurement has the same purpose. Note the
value for the file in your original post: -9.1 dB. That means
that an intelligent mp3 player will *reduce* the level of this
file by 9.1 dB when playing it - it is already much too loud.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
29 Jul
29 Jul
1:50 a.m.
I'm sure it's been answered many times, but here's my question:
For loudness evaluation, how's EBU R128 "better" than ReplayGain?
(Or why use EBU R128 instead of ReplayGain?)
(A link to the suitable InterWeb resource would be appropriate)
B.T.W, there's another EBU R128 utility to normalize audio files:
https://github.com/jiixyj/libebur128
It can add ReplayGain tags to existing mp3 files. Nice!
I add to checkout commit 1c0e8da to avoid linking errors,
as mentioned here:
https://github.com/jiixyj/libebur128/issues/20
--
Marc
Fons Adriaensen <fons(a)linuxaudio.org> a écrit :
--
Marc
I assume the
ebumeter output is more for making things sound even
(between different pieces) and not directly a tool to max out
anything, is that right?
That is absolutely right. Systems such as EBU-R128 exist because
it makes perfect sense to make things sound even (avoiding your
listeners having to adjust the volume all the time), while 'maxing
out' serves no useful purpose at all - it just destroys the sound
if taken too far. In other words, such systems exist to *stop* you
'maxing out' everything.
Lame's 'replaygain' meausurement has the same purpose. Note the
value for the file in your original post: -9.1 dB. That means
that an intelligent mp3 player will *reduce* the level of this
file by 9.1 dB when playing it - it is already much too loud. 
3:27 a.m.
On 07/29/2013 01:50 AM, Marc Lavallée wrote:
I'm sure it's been answered many times, but here's my question:
For loudness evaluation, how's EBU R128 "better" than ReplayGain?
(Or why use EBU R128 instead of ReplayGain?)
(A link to the suitable InterWeb resource would be appropriate)
ReplayGain is a laudable effort at solving the issue of arbitrary
loudness jumps for audio consumers. More power to them :)
However, I believe the psychoacoustic "model" of EBU R128 is superior,
although certainly not perfect (colleagues have mentioned to me ways of
cheating R128 to achieve higher programme loudness for constant LUFS
readings, but I've yet to see an actual demonstration).
But regardless of technical merit, I would always choose EBU 128 over
ReplayGain, because it has the magic letters "EBU" in it, and the
underlying measurement scheme has the even more magic "ITU".
Don't forget that any perceptive loudness normalization proposal is
basically a "non-agression pact" in the loudness war. If you don't nuke
my speakers (and wreck my music), I won't nuke yours. So it makes sense
to flock around the biggest fish in the pond, because their involvement
and statement of intent carries weight.
Until all broadcasters follow suit, those who behave are at a commercial
disadvantage, so the whole process has all the interesting properties of
a game theory problem.
For an euro-centric bastard like me, the European Broadcast Union is the
mightiest normative entity in the universe. Some weird people think
differently, but those take solace in the fact that the actual loudness
determination is governed by an International Telecommunication Union
standard (and that should be good enough for everyone :)
So yes, R128 is a very safe bet indeed.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
11:25 a.m.
On Sun, Jul 28, 2013 at 07:50:44PM -0400, Marc Lavallée wrote:
I'm sure it's been answered many times, but
here's my question:
For loudness evaluation, how's EBU R128 "better" than ReplayGain?
(Or why use EBU R128 instead of ReplayGain?)
(A link to the suitable InterWeb resource would be appropriate)
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_1.0_specification
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_2.0_specification
The proposed RG2 spec uses the same algorithm as R-128.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:45 a.m.
On Mon, 29 Jul 2013 09:25:31 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Jul 28, 2013 at 07:50:44PM -0400, Marc
Lavallée wrote:
One of the first things I thought when I saw the R-128 talk was" Could
this be used for a better replaygain?". Very nice to see that such an
effort is underway.
Now the obvious question is: Will this work better than the old replay
gain, and by how much? Has anyone done tests?
Regards,
Philipp
I'm sure it's been answered many times,
but here's my question:
For loudness evaluation, how's EBU R128 "better" than ReplayGain?
(Or why use EBU R128 instead of ReplayGain?)
(A link to the suitable InterWeb resource would be appropriate)
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_1.0_specification
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_2.0_specification
The proposed RG2 spec uses the same algorithm as R-128.
Ciao,
12:13 p.m.
On Mon, Jul 29, 2013 at 11:45:01AM +0200, Philipp Überbacher wrote:
On Mon, 29 Jul 2013 09:25:31 +0000 Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
See the Dolby paper referenced in the second link.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_1.0_specification
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_2.0_specification
The proposed RG2 spec uses the same algorithm as R-128.
One of the first things I thought when I saw the R-128 talk was" Could
this be used for a better replaygain?". Very nice to see that such an
effort is underway.
Now the obvious question is: Will this work better than the old replay
gain, and by how much? Has anyone done tests?
3:27 p.m.
On Mon, 29 Jul 2013 10:13:16 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Mon, Jul 29, 2013 at 11:45:01AM +0200, Philipp
Überbacher wrote:
Thanks Fons,
while the paper
(http://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/
AES128-Loudness-Normalization-Portable-Media-Players.pdf)
is interesting, it's not what I was looking for. What needs testing is
whether the loudness adjustment of RG2 compared to RG1 is perceived as
'closer to equal loudness'. When some sort of actual listening test
shows that RG2 performs significantly better, good, otherwise I don't
see the point.
I do find their recommended conversion equation questionable, they came
up with it based on their sample set plus thumb measure. There's no
telling what the results will be, but I don't expect them to be any
good.
Regards,
Philipp
On Mon, 29 Jul 2013 09:25:31 +0000 Fons
Adriaensen
<fons(a)linuxaudio.org> wrote:
See the Dolby paper referenced in the second link.
Ciao,
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_1.0_specification
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_2.0_specification
The proposed RG2 spec uses the same algorithm as R-128.
One of the first things I thought when I saw the R-128 talk was"
Could this be used for a better replaygain?". Very nice to see that
such an effort is underway.
Now the obvious question is: Will this work better than the old
replay gain, and by how much? Has anyone done tests?
4:15 p.m.
On Mon, Jul 29, 2013 at 03:27:33PM +0200, Philipp Überbacher wrote:
while the paper
(http://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/
AES128-Loudness-Normalization-Portable-Media-Players.pdf)
is interesting, it's not what I was looking for. What needs testing is
whether the loudness adjustment of RG2 compared to RG1 is perceived as
'closer to equal loudness'. When some sort of actual listening test
shows that RG2 performs significantly better, good, otherwise I don't
see the point.
ITU-1770 on which both R-128 and RG2 are based has been tested extensively
over a long time and shown to work very well. AFAIK there was no comparable
amount of testing done on RG1.
I do find their recommended conversion equation
questionable, they came
up with it based on their sample set plus thumb measure. There's no
telling what the results will be, but I don't expect them to be any
good.
Why not ? The tests on the sample set (which is not small) show quite
a good agreement between the two systems.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
6:22 p.m.
On Mon, 29 Jul 2013 14:15:28 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
According to the R-128 paper the standard deviation of their samples
from the line they plotted there is 1dB, no idea what it is from the
slope (-1) they guessed there. Still, given to songs it could well be
2dB or more off, but my main point is that this is still with _their_
data set. I guess that with another data set the differences could be
larger and significant to the point where the error is large enough for
the conversion to be a bad thing™.
I wonder whether a better, albeit slightly more complicated way of
conversion can be found, this one was apparently chosen primarily for
its simplicity.
Don't get me wrong, I like ReplayGain, and I'd like to see further
adoption, I'm just not sure the R-128 based one will actually be better
and cause further adoption. I fear it could cause confusion and further
problems instead. Sometimes I also like to argue and see the bad parts
in everything.
On the upside, the temperature just dropped below 30° for a
change.
Have a nice day,
Philipp
On Mon, Jul 29, 2013 at 03:27:33PM +0200, Philipp
Überbacher wrote:
Really? I can't find any proper references, at least not in the latest
version of the ITU-1770 paper
(http://www.itu.int/rec/R-REC-BS.1770-3-201208-I/en). They only roughly
describe some tests, first as mostly female speech (p. 13-14), later
they claim it was a broad base of material (p. 18). I can't see any
obvious reference to details of those tests, the second referenced
paper (Evaluation of Objective Loudness Meters) seems to describe it,
but it seems this paper is not publicly accessible.
However, my point here is that it has to show its performance and
especially superiority over the established RG1 in practice, everything
else is of little significance.
while the paper
(http://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/
AES128-Loudness-Normalization-Portable-Media-Players.pdf)
is interesting, it's not what I was looking for. What needs testing
is whether the loudness adjustment of RG2 compared to RG1 is
perceived as 'closer to equal loudness'. When some sort of actual
listening test shows that RG2 performs significantly better, good,
otherwise I don't see the point.
ITU-1770 on which both R-128 and RG2 are based has been tested
extensively over a long time and shown to work very well. AFAIK there
was no comparable amount of testing done on RG1. I do find
their recommended conversion equation questionable, they
came up with it based on their sample set plus thumb measure.
There's no telling what the results will be, but I don't expect
them to be any good.
Why not ? The tests on the sample set (which is not small) show quite
a good agreement between the two systems.
Ciao,
8:13 p.m.
To get back to the original discussion - I feel very enlightened now
and have to re-do everything I did in the last years. Thanks, guys,
or something :-)
I have a question left, and that is that from my observation lame is
unable to predict the "correct" gain level. Lame gives you a db value
that you can use as adjustment on the input so that you don't clip, or
how many db you are under, respectively.
I find that lowering the gain by what lame suggested in the first run
will still randomly lead to clipping and lame going back suggesting
even lower values.
Is this an inherit problem that lame can't possibly do an exact job?
I just wish lame had an option to just read the whole clip and noodle
around until it gets to a level it's happy with.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/
9:56 p.m.
On Mon, Jul 29, 2013 at 02:13:29PM -0400, Martin Cracauer wrote:
I find that lowering the gain by what lame suggested
in the first run
will still randomly lead to clipping and lame going back suggesting
even lower values.
Is this an inherit problem that lame can't possibly do an exact job?
Maybe.
I just wish lame had an option to just read the whole
clip and noodle
around until it gets to a level it's happy with.
You could probably avoid all these issues by not trying to get
the maximum level in the first place. If you record/master at
normal levels lame won't have any problems with your signals at
all.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
28 Jul
28 Jul
6:45 a.m.
Hi Martin.
The "r128gain" software is not the same than "ebur128" that comes
with ebumeter. R128gain can be used to convert your files to mp3 in one
pass, while ebur128 analyse and report.
My understanding of EBU R128: what's important is the "integrated
loudness"; the recommended value is -23 LUFS. If you run ebur128
without --lusfs, the integrated loudness would be -4.9 - -23 = 18.1
So you would have to reduce the volume by 18.1dB.
--
Marc
Martin Cracauer <cracauer(a)cons.org> a écrit :
Thanks again. Things are looking much better now. I
embraced the
concept of not being able to predict this. Turns out I have old
screwed up things that really benefitted from revisiting them and
cleaning them up.
Marc Lavall??e wrote on Thu, Jul 25, 2013 at 04:45:48PM -0400:
Martin Cracauer <cracauer(a)cons.org> a
??crit :
That works. Comes in the Debian ebumeter package, BTW.
But how do I translate the output to a required db or ratio
adjustment?
I have a file in front of me that was maxed out amplitude wise by
somebody else. According to lame I needed --scale 0.64 to get it not
to clip in lame (should be 3.9 db). Which, BTW was not the value it
first estimated that I would need.
ebur128 --lufs:
Integrated loudness: -4.9 LUFS
Loudness range: 5.5 LU
Integrated threshold: -13.0 LUFS
Range threshold: -25.0 LUFS
Range min: -8.6 LUFS
Range max: -3.1 LUFS
Momentary max: -1.2 LUFS
Short term max: -2.4 LUFS
I don't see that any of the value correspond with what lame needed to
not clip over a collection of different loudness clips. (means: some
clips that needed less --scale have higher numbers here and others
have lower)
I assume the ebumeter output is more for making things sound even
(between different pieces) and not directly a tool to max out
anything, is that right?
Martin Is there a way to hook up ebumeter to just an
audio file or a
stream not associated with real time? It seems to come in a jack
package only.
Thanks again
Martin
http://r128gain.sourceforge.net/
1:27 p.m.
On Sun, Jul 28, 2013 at 12:45:00AM -0400, Marc Lavallée wrote:
The "r128gain" software is not the same than
"ebur128" that comes
with ebumeter.
And where is the source code ? The SF packages contain a copy
of the GPL, and *only* binaries and shared libraries (which
probably shouldn't get installed that way on any system).
The SVN links don't work. Something stinks here.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
1:47 p.m.
On Sun, 2013-07-28 at 11:27 +0000, Fons Adriaensen wrote:
And where is the source code ?
The SVN links don't work.
For the other projects the SVN addresses don't exist too
http://sourceforge.net/u/pbelkner/profile/
2 p.m.
Am Sonntag, 28. Juli 2013, 11:27:34 schrieb Fons Adriaensen:
On Sun, Jul 28, 2013 at 12:45:00AM -0400, Marc
Lavallée wrote:
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/
lists a src.tar.gz that is downloadable via
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/r128gain-1.0-sr…
Edgar
The "r128gain" software is not the same
than "ebur128" that comes
with ebumeter.
And where is the source code ? The SF packages contain a copy
of the GPL, and *only* binaries and shared libraries (which
probably shouldn't get installed that way on any system). The SVN links don't work. Something stinks here.
Ciao,
2:44 p.m.
On 07/28/2013 01:27 PM, Fons Adriaensen wrote:
On Sun, Jul 28, 2013 at 12:45:00AM -0400, Marc
Lavallée wrote:
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/r128gain-1.0-sr…
haven't tried to build it, but it looks like a sane and complete source
package after a cursory glance.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
The "r128gain" software is not the same
than "ebur128" that comes
with ebumeter.
And where is the source code ?
3:20 p.m.
On Sun, 2013-07-28 at 14:44 +0200, Jörn Nettingsmeier wrote:
On 07/28/2013 01:27 PM, Fons Adriaensen wrote:
Isn't there the need to provide all used sources instead of downloading
them? However, I don't care about it.
$ grep DOWNLOAD Makefile
define DOWNLOAD
$(call DOWNLOAD,ftp://ftp.nluug.nl/pub/ImageMagick/$(@F))
# $(call DOWNLOAD,ftp://mirror.checkdomain.de/imagemagick/$(@F))
$(call DOWNLOAD,http://www.ijg.org/files/jpegsrc.v$(JPEG_VER).tar.gz)
$(call DOWNLOAD,http://ffmpeg.org/releases/$(@F))
$(call DOWNLOAD,$(call SFURL,sox,sox/$(SOXVER)/$(@F)))
$(call DOWNLOAD,http://www.wavpack.com/$(@F))
$(call DOWNLOAD,$(call SFURL,flac,flac-src/$(FLAC)-src/$(@F)))
$(call
DOWNLOAD,ftp://ftp.videolan.org/pub/videolan/x264/snapshots/$(@F))
$(call DOWNLOAD,http://webm.googlecode.com/files/$(@F))
$(call DOWNLOAD,http://www.mega-nerd.com/libsndfile/files/$(@F))
$(call DOWNLOAD,http://downloads.xiph.org/releases/opus/$(@F))
$(call DOWNLOAD,http://downloads.xiph.org/releases/vorbis/$(@F))
$(call DOWNLOAD,http://downloads.xiph.org/releases/ogg/$(@F))
$(call DOWNLOAD,$(call SFURL,lame,lame/$(LAME_MAJOR)/$(@F)))
$(call DOWNLOAD,ftp://sourceware.org/pub/pthreads-win32/$(@F))
$(call DOWNLOAD,http://www.tortall.net/projects/yasm/releases/$(@F))
$(call DOWNLOAD,http://pkgconfig.freedesktop.org/releases//$(@F))
FWIW it didn't build by the first trial on Arch Linux:
$ wget
http://kent.dl.sourceforge.net/project/r128gain/r128gain/1.0/r128gain-1.0-s…
[snip]
cc1: all warnings being treated as errors
make[2]: *** [gtkgui.o] Error 1
rm r128gain_mkdir.o r128gain_s_rg.o r128gain_sink.o r128gain_cmd.o
r128gain_y.o r128gain_reg.o r128gain_f_ff.o r128gui_io.o r128gain_s.o
r128gain_peak.o r128gui_util.o r128gain_f_sox.o r128gain_ps.o
r128gui_ps.o r128gain_s_r128.o r128gain_meta.o r128gain_f.o
make[2]: Leaving directory
`/usr/src/r128gain-1.0/full/gtk3/build/r128gain'
make[1]: *** [full/gtk3/build/r128gain/r128gain] Error 2
make[1]: Leaving directory `/usr/src/r128gain-1.0'
make: *** [all-full-gtk3] Error 2
Regards,
Ralf
On Sun, Jul 28, 2013 at 12:45:00AM -0400, Marc
Lavallée wrote:
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/r128gain-1.0-sr…
haven't tried to build it, but it looks like a sane and complete source
package after a cursory glance. The "r128gain" software is not the same
than "ebur128" that comes
with ebumeter.
And where is the source code ?
4:21 p.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> a écrit :
Isn't there the need to provide all used sources
instead of
downloading them? However, I don't care about it.
I tried to compile it. Here's what I did.
# I downloaded the source files in the same folder:
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/r128gain-1.0-sr…
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/r128gain-1.0-to…
# I unarchived them:
tar -xzf r128gain-1.0-src.tar.gz
tar -xzf r128gain-1.0-tools.tar.gz
# I jumped into the resulting source folder:
cd r128gain-1.0
# I start rebuilding the world (it's a llloong process):
./configure
cmake
make
# I tried to install it:
sudo make install
But it didn't work, complaining about a missing sox development
package. So I stopped. You're welcome to give it a try. There's
probably a way to compile r128gain without compiling all the required
libraries, in order to use the already installed system libraries.
As a casual user, the binaries works fine, although I had to
symlink the liblame library in the r128gain-tools folder (liblame is
probably missing for copyright issues); for now I believe it's the
easiest way to install r128gain, until official packages appears in
popular Linux based distributions.
--
Marc
29 Jul
29 Jul
3:29 a.m.
On 07/28/2013 03:20 PM, Ralf Mardorf wrote:
On Sun, 2013-07-28 at 14:44 +0200, Jörn Nettingsmeier
wrote:
no, there isn't. it is neither required by the gpl, nor would it be
useful except in very rare cases.
On 07/28/2013 01:27 PM, Fons Adriaensen wrote:
Isn't there the need to provide all used sources instead of downloading
them? On Sun, Jul 28, 2013 at 12:45:00AM -0400, Marc
Lavallée wrote:
http://sourceforge.net/projects/r128gain/files/r128gain/1.0/r128gain-1.0-sr…
haven't tried to build it, but it looks like a sane and complete source
package after a cursory glance. The "r128gain" software is not the same
than "ebur128" that comes
with ebumeter.
And where is the source code ? However, I don't care about it.
sigh.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
8 a.m.
On Mon, 2013-07-29 at 03:29 +0200, Jörn Nettingsmeier wrote:
On 07/28/2013 03:20 PM, Ralf Mardorf wrote:
Ok. I'm aware that a coder can add a list of dependencies, but I thought
if it ignores installed dependencies and include it to the own source
code, it also must be provided by the own source code. It was the first
time I saw "make" downloading dependencies and I'm surprised, since the
dependencies were already installed.
Thank you Jörn,
Ralf
On Sun, 2013-07-28 at 14:44 +0200, Jörn
Nettingsmeier wrote:
Isn't there the need to provide all used sources instead of downloading
them?
no, there isn't. it is neither required by the gpl, nor would it be
useful except in very rare cases. 
25 Jul
25 Jul
11:09 p.m.
On Thu, 25 Jul 2013 16:14:20 -0400
Martin Cracauer <cracauer(a)cons.org> wrote:
Fons Adriaensen wrote on Thu, Jul 25, 2013 at
07:40:53PM +0000:
I always finalise a wav file in Audacity with the peak level at -1dB. Seems to
work for me :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On Thu, Jul 25, 2013 at 02:21:50PM -0400, Martin
Cracauer wrote:
Ah. Makes sense. Thanks so much!
Is there a rule of thumb how many db less I should give music to avoid
this? What would be the value for pink noise starting at 40 Hz? Does anybody know why wav files that do not have
clipping would clip
when encoding them with lame?
Because the peak sample value says nothing about the real
level. Take a square wave with peak values +/-1. It is the
sum of a number of sine waves, with frequencies 1,3,5,7,...
times the frequency of the square wave. The first one has
a peak value of about +/-1.27, that is +2 dB. So any encoding
that looks at the spectrum (and mp3 does) will see a level
that is +2 dB.
11:44 p.m.
On Thu, Jul 25, 2013 at 04:14:20PM -0400, Martin Cracauer wrote:
Is there a rule of thumb how many db less I should
give music
to avoid this?
Depends entirely on what you are trying to do, what sort of
signals/music you have, how the clips are going to be used,
and where you stand in the 'loudness wars'.
'Acoustic' music has a peak/RMS ratio of around 20 dB.
The EBU standard means to aim for an average RMS level of
-23 dB. Most popular music productions try to have a much
higher average level, and hence a lower peak/RMS ratio,
something like 10 dB, or 6 dB for the more agressive ones,
and as low as 3 dB if the target audience is the braindead.
OTOH, if your clips are e.g. unprocessed drum samples, you
could have a peak/RMS ratio that is much higher than 20 dB.
So it depends, use your judgement.
What would be the value for pink noise starting at 40
Hz?
Impossible to say. Gaussian noise (analog noise is Gaussian)
has in theory an infinite peak/RMS ratio. In practice it will
be limited of course.
To get an idea of this, you could measure the pink noise
provided by e.g. japa with jkmeter (which shows RMS and peak).
The RMS value is -20 dB. If you wait long enough, the peak
memory can take any value, there is no limit.
In practice, if one or few samples per second get clipped
you won't notice.
Is there a way to hook up ebumeter to just an audio
file or a stream
not associated with real time? It seems to come in a jack package only.
If you have ebumeter installed, try
ebur128 --full --lufs filename.wav
The ebur128 program is included in the source distribution
of ebumeter, I don't know if it's available in binary packages.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
26 Jul
26 Jul
6:29 a.m.
On Thu, 2013-07-25 at 21:44 +0000, Fons Adriaensen wrote:
as low as 3 dB if the target audience
^ and the engineer and the
producer are the braindead. No engineer or producer is forced to do bad
recordings. The target group is naive and only sometimes braindead.
Engineers and producers permanently doing this are the braindead.
3932
days inactive
3936
days old
linux-audio-user@lists.linuxaudio.org
29 comments
8 participants
participants (8)
-
Edgar Aichinger -
Fons Adriaensen -
Jörn Nettingsmeier -
Marc Lavallée -
Martin Cracauer -
Philipp Überbacher -
Ralf Mardorf -
Will Godfrey