5 Nov
2020
5 Nov
'20
11:06 p.m.
Wondering if there's a command line (scriptable) recorder for Jack
which will record for a configurable duration. Because:
I've been using Jack TimeMachine to record in its default 'w64' format
and then converting to wav with sox like:
sox --no-clobber -S tm-2020-10-27T22:00:15.w64 -b 16 /home/john/2710.wav
It all works well and sox stat shows min and max amplitude -0.9 and 0.9
I need to make the recordings automatic and arecord seems to fit the bill
with its ability to record for a number of seconds with -d, but the level
seems much lower. I used PulseAudio Volume Control to get something like
a good level with 150% on the input sliders (10.53dB) and I still only
see around -0.5 and 0.5 using sox stat. They only go up to 11dB.
I don't like pushing levels that far and it isn't enough anyway. Something
seems very wrong with Pulse / Alsa although Jack uses Driver: alsa.
PAVolume Control > Input Devices shows UltraLite AVB Multichannel
Port: Multichannel Input
Front Left (where the inputs levels are)
Front Right "
6 other position channels (showing no input level)
16 Auxiliary channels "
--
Thanks again,
John.
5 Nov
5 Nov
11:31 p.m.
On Thu, Nov 05, 2020 at 09:06:19PM +0000, John Murphy wrote:
Wondering if there's a command line (scriptable)
recorder for Jack
which will record for a configurable duration. Because:
I've been using Jack TimeMachine to record in its default 'w64' format
and then converting to wav with sox like:
sox --no-clobber -S tm-2020-10-27T22:00:15.w64 -b 16 /home/john/2710.wav
It all works well and sox stat shows min and max amplitude -0.9 and 0.9
I need to make the recordings automatic and arecord seems to fit the bill
with its ability to record for a number of seconds with -d, but the level
seems much lower. I used PulseAudio Volume Control to get something like
a good level with 150% on the input sliders (10.53dB) and I still only
see around -0.5 and 0.5 using sox stat. They only go up to 11dB.
First advice: get rid of PA and its braindead controls. If you disable
PA when using Jack, do the same when using arecord.
Then recording using arecord or jack with the ALSA backend (using the
same sound card in both cases of course) should give the same result.
In both cases that will depend on the alsamixer settings if there any
for your sound card.
The difference between +/-0.9 and +/-0.5 is actually quite small (less
than 6 dB). It doesn't tell you anything unless you can ensure you
recorded exactly the same signal in both cases. Normal audio signals
(speech, music,...) have level variations that are much bigger than
6 dB.
Ciao,
--
FA
6 Nov
6 Nov
12:39 a.m.
On Thu, 5 Nov 2020 22:31:39 +0100 Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Many thanks for the fast reply. Recording the old way in progress
currently, so I can't try anything else today.
On Thu, Nov 05, 2020 at 09:06:19PM +0000, John Murphy
wrote:
Can't seem to do that, unfortunately.
Wondering if there's a command line
(scriptable) recorder for Jack
which will record for a configurable duration. Because:
I've been using Jack TimeMachine to record in its default 'w64' format
and then converting to wav with sox like:
sox --no-clobber -S tm-2020-10-27T22:00:15.w64 -b 16 /home/john/2710.wav
It all works well and sox stat shows min and max amplitude -0.9 and 0.9
I need to make the recordings automatic and arecord seems to fit the bill
with its ability to record for a number of seconds with -d, but the level
seems much lower. I used PulseAudio Volume Control to get something like
a good level with 150% on the input sliders (10.53dB) and I still only
see around -0.5 and 0.5 using sox stat. They only go up to 11dB.
First advice: get rid of PA and its braindead controls. If you disable
PA when using Jack, do the same when using arecord. Then recording using arecord or jack with the ALSA
backend (using the
same sound card in both cases of course) should give the same result.
In both cases that will depend on the alsamixer settings if there any
for your sound card.
Alsamixer shows nothing configurable for the (USB) card and using the
same arecord command (arecord -f dat -d 10 test.wav) records silence.
The difference between +/-0.9 and +/-0.5 is actually
quite small (less
than 6 dB). It doesn't tell you anything unless you can ensure you
recorded exactly the same signal in both cases. Normal audio signals
(speech, music,...) have level variations that are much bigger than
6 dB.
Good point. It's mainly that the level will just look wrong in the
visual editor I use. My tests have been much shorter, but sox stat
is suggesting Volume adjustment: 1.868 and 1.662 on new files made
with +10dB (according to Pulse) and 1.000 for a previous recording
made with jack TimeMachine.
--
Thanks again,
John.
12:17 p.m.
On Thu, Nov 05, 2020 at 10:38:39PM +0000, John Murphy wrote:
Something like
pasuspender -- jackd ...
pasuspender -- arecord ...
should do it.
This temporarily suspends PA while the command after -- runs,
There are also ways disable PA permanently.
But I'm not a PA expert, I just don't install it.
--
FA
First advice:
get rid of PA and its braindead controls. If you disable
PA when using Jack, do the same when using arecord.
Can't seem to do that, unfortunately.
12:56 p.m.
On Fri, 6 Nov 2020 11:17:30 +0100 Fons Adriaensen wrote:
On Thu, Nov 05, 2020 at 10:38:39PM +0000, John Murphy
wrote:
Something like
pasuspender -- jackd ...
pasuspender -- arecord ...
should do it.
This temporarily suspends PA while the command after -- runs,
There are also ways disable PA permanently.
But I'm not a PA expert, I just don't install it.
Thank you again. I'll try that, but I've found that jack_capture has a
--recording-time Additional argument and says that it 'can connect to
any input or output jack port'. I saw it mentioned at
https://jackaudio.org/applications/
but the link didn't take me anywhere useful, so I looked elsewhere eventually.
https://github.com/kmatheussen/jack_capture
is a better source.
You'll understand I'd rather use jack if possible. :)
--
Thanks again,
John.
First
advice: get rid of PA and its braindead controls. If you disable
PA when using Jack, do the same when using arecord.
Can't seem to do that, unfortunately.
1:16 p.m.
On Fri, Nov 06, 2020 at 10:55:38AM +0000, John Murphy wrote:
You'll understand I'd rather use jack if
possible. :)
Of course, but even then you'd have to get PA out of the way.
One way would be to configure PA to not use the sound card
you want to use with Jack. See PA docs :-)
Ciao,
--
FA
2:23 p.m.
On Fri, 6 Nov 2020 12:16:05 +0100
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Fri, Nov 06, 2020 at 10:55:38AM +0000, John Murphy
wrote:
I never want pulseaudio at all, but lots of programs I use insist on it these
days. The complete solution I've come up with is to delete just the server,
leaving the rest in place.
All the programs are happy talking to the client, the client doesn't see a
server so just does nothing. The audio stuff I want to run works uninhibited.
--
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.
You'll understand I'd rather use jack if
possible. :)
Of course, but even then you'd have to get PA out of the way.
3:23 p.m.
On Fri, 6 Nov 2020 12:16:05 +0100 Fons Adriaensen wrote:
On Fri, Nov 06, 2020 at 10:55:38AM +0000, John Murphy
wrote:
It's usually just set 'off' in PAVolumeControl. Seems to stay that way.
Pulse gets to use the onboard soundcard. The line out is connected
to an input on the USB interface. VLC, firefox etc. are happy.
I think I've discovered where my levels were going awry. I was using
timemachine to record in w64 format and converting to wav. Now, using:
jack_capture -s --channels 2 --port system:capture* -d 10 -f w64 t1w64.w64 \
& jack_capture -s --channels 2 --port system:capture* -d 10 -f wav t1wav.wav
then:
sox --no-clobber -S t1w64.w64 -b 16 t2wav.wav
Then sox stat shows min/max amplitude +/- 0.5 for the wav capture and
+/- 0.9 for the wav converted from w64. The converted file looks good
in my editor too.
--
Thanks again,
John.
You'll understand I'd rather use jack if
possible. :)
Of course, but even then you'd have to get PA out of the way.
One way would be to configure PA to not use the sound card
you want to use with Jack. See PA docs :-)
4:07 p.m.
On Fri, Nov 06, 2020 at 01:22:42PM +0000, John Murphy wrote:
Then sox stat shows min/max amplitude +/- 0.5 for the
wav capture and
+/- 0.9 for the wav converted from w64. The converted file looks good
in my editor too.
Still doesn't explain the difference, unless I'm missing something...
--
FA
5:07 p.m.
On Fri, 6 Nov 2020 15:07:43 +0100 Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Fri, Nov 06, 2020 at 01:22:42PM +0000, John Murphy
wrote:
There's a loss of precision in the conversion process. Both the original
recordings show 25 bit precision and the file sizes are the same (3.8MB).
The converted file is only 16 bit and is 1.9MB. It sounds (and looks)
louder. I doubt I could tell any loss of quality. Not explaining it.
Just providing some facts. :)
--
Thanks again,
John.
Then sox stat shows min/max amplitude +/- 0.5 for
the wav capture and
+/- 0.9 for the wav converted from w64. The converted file looks good
in my editor too.
Still doesn't explain the difference, unless I'm missing something...
7 Nov
7 Nov
3:19 a.m.
On 11/6/20 10:06 AM, John Murphy wrote:
On Fri, 6 Nov 2020 15:07:43 +0100 Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Maybe this is relevant?
According to my package manager, sox depends on libsndfile.
On the libsndfile website:
http://www.mega-nerd.com/libsndfile/api.html#note1
it talks about normalization:
"When converting between integer data and floating point data, different
rules apply.
The default behaviour when reading floating point data (sf_read_float()
or sf_read_double ())
from a file with integer data is normalisation. Regardless of whether
data in the file
is 8, 16, 24 or 32 bit wide, the data will be read as floating point
data in the range [-1.0, 1.0].
Similarly, data in the range [-1.0, 1.0] will be written to an integer
PCM file so that
a data value of 1.0 will be the largest allowable integer for the
given bit width.
This normalisation can be turned on or off using the sf_command
<http://www.mega-nerd.com/libsndfile/command.html> interface"
I recall observing that this normalization does tend to make the result
'louder'.
Could this be what is being observed?
Tim.
On Fri, Nov 06, 2020 at 01:22:42PM +0000, John
Murphy wrote:
There's a loss of precision in the conversion process. Both the original
recordings show 25 bit precision and the file sizes are the same (3.8MB).
The converted file is only 16 bit and is 1.9MB. It sounds (and looks)
louder. I doubt I could tell any loss of quality. Not explaining it.
Just providing some facts. :)
Then sox stat shows min/max amplitude +/- 0.5 for
the wav capture and
+/- 0.9 for the wav converted from w64. The converted file looks good
in my editor too.
Still doesn't explain the difference, unless I'm missing
something...
9:03 a.m.
On Fri, 6 Nov 2020 20:19:02 -0500 "Tim E. Real" wrote:
On 11/6/20 10:06 AM, John Murphy wrote:
That would seem to explain it and the output of sndfile-info appears
to confirm (see my reply to Chris). Quite surprised it does that extra
thing for me.
Thanks all.
--
Thanks again,
John.
On Fri, 6 Nov 2020 15:07:43 +0100 Fons Adriaensen
wrote:
Maybe this is relevant?
According to my package manager, sox depends on libsndfile.
On the libsndfile website:
http://www.mega-nerd.com/libsndfile/api.html#note1
it talks about normalization:
"When converting between integer data and floating point data, different
rules apply.
The default behaviour when reading floating point data (sf_read_float()
or sf_read_double ())
from a file with integer data is normalisation. Regardless of whether
data in the file
is 8, 16, 24 or 32 bit wide, the data will be read as floating point
data in the range [-1.0, 1.0].
Similarly, data in the range [-1.0, 1.0] will be written to an integer
PCM file so that
a data value of 1.0 will be the largest allowable integer for the
given bit width.
This normalisation can be turned on or off using the sf_command
<http://www.mega-nerd.com/libsndfile/command.html> interface"
I recall observing that this normalization does tend to make the result
'louder'.
Could this be what is being observed? On Fri, Nov 06, 2020 at 01:22:42PM +0000, John
Murphy wrote:
There's a loss of precision in the conversion process. Both the original
recordings show 25 bit precision and the file sizes are the same (3.8MB).
The converted file is only 16 bit and is 1.9MB. It sounds (and looks)
louder. I doubt I could tell any loss of quality. Not explaining it.
Just providing some facts. :)
Then sox stat shows min/max amplitude +/- 0.5 for
the wav capture and
+/- 0.9 for the wav converted from w64. The converted file looks good
in my editor too.
Still doesn't explain the difference, unless I'm
missing something...
6 Nov
6 Nov
11:20 p.m.
On Fri, November 6, 2020 7:22 am, John Murphy wrote:
I think I've discovered where my levels were going
awry. I was using
timemachine to record in w64 format and converting to wav. Now, using:
jack_capture -s --channels 2 --port system:capture* -d 10 -f w64 t1w64.w64
\
& jack_capture -s --channels 2 --port system:capture* -d 10 -f wav
t1wav.wav
then:
sox --no-clobber -S t1w64.w64 -b 16 t2wav.wav
Then sox stat shows min/max amplitude +/- 0.5 for the wav capture and
+/- 0.9 for the wav converted from w64. The converted file looks good
in my editor too.
The w64 vs. wav file thing is not relevant unless you are recording for
more than a couple of hours at a time. The important distinction is that
jack_capture records as single precision floating point values by default,
and the "-b 16" argument to sox converts to 16 bit integer PCM.
What does sndfile-info show about t1w64.w64 and t2wav.wav files? I tried
using sox to convert a float file I had in an Ardour project directory to
PCM, and sndfile-info reported the exact same maximum value for both.
Using the sox stat effect also displayed the same maximum and minimum for
original and converted file as well, but sndfile-info might give you some
insight into why sox did not seem to show the same value.
--
Chris Caudle
7 Nov
7 Nov
9:05 a.m.
On Fri, 6 Nov 2020 15:19:22 -0600 "Chris Caudle" wrote:
What does sndfile-info show about t1w64.w64 and
t2wav.wav files? I tried
using sox to convert a float file I had in an Ardour project directory to
PCM, and sndfile-info reported the exact same maximum value for both.
Using the sox stat effect also displayed the same maximum and minimum for
original and converted file as well, but sndfile-info might give you some
insight into why sox did not seem to show the same value.
Side by side for easy comparison:
File : t1w64.w64 t2wav.wav
Length : 3840136 1920044
riff : 3840136 1920036
wave
fmt : 40 16
Format : 0x3 => WAVE_FORMAT_IEEE_FLOAT 0x1 => WAVE_FORMAT_PCM
Channels : 2 2
Sample Rate : 48000 48000
Block Align : 8 4
Bit Width : 32 16
Bytes/sec : 384000 192000
fact : 32
frames : 480000
data : 3840024
End
-----------------------------------------------------------------------
Sample Rate : 48000 48000
Frames : 480000 480000
Channels : 2 2
Format : 0x000B0006 0x00010002
Sections : 1 1
Seekable : TRUE TRUE
Duration : 00:00:10.000 00:00:10.000
Signal Max : 0.584686 (-4.66 dB) 32767 (-0.00 dB)
That last 'Signal Max' comparison does seem to confirm that
normalisation has occurred.
--
Thanks again,
John.
9:58 a.m.
Next question then: how do I denormalise about 100GB of recordings? :)
I had thought I noticed a difference between listening to the live shows
and the recordings. A slight dullness / lack of sparkle. I put it down
to being the only listener to the recordings, but part of a synchronised
audience originally (I'm sure there's something to that, even while
different speed processes cause smaller synchronised groups), or my
imagination.
Of course; I'll be quite convinced that my future recordings sound
much better without normalisation...
I really appreciate the help from everyone.
Thanks.
--
10 Nov
10 Nov
12:51 a.m.
You cannot denormalize unless you have a peak value for each of the
originals. If you have the originals, use sndfile-info to get the peak
value, then use sox or similar to change the converted files. OTOH, this is
going to be no faster than reconverting all them again.
On Sat, Nov 7, 2020 at 12:58 AM John Murphy <rosegardener(a)freeode.co.uk>
wrote:
Next question then: how do I denormalise about 100GB
of recordings? :)
I had thought I noticed a difference between listening to the live shows
and the recordings. A slight dullness / lack of sparkle. I put it down
to being the only listener to the recordings, but part of a synchronised
audience originally (I'm sure there's something to that, even while
different speed processes cause smaller synchronised groups), or my
imagination.
Of course; I'll be quite convinced that my future recordings sound
much better without normalisation...
I really appreciate the help from everyone.
Thanks.
--
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
1:12 a.m.
On Sat, November 7, 2020 1:04 am, John Murphy wrote:
On Fri, 6 Nov 2020 15:19:22 -0600 "Chris
Caudle" wrote:
That is different than the results on my system, even though I used the
same SoX command line you showed before. I don't know if that implies
some difference between versions of SoX, or different compile time
options, or different versions of sndfile-lib installed on my system
(Fedora 33 just for info).
sox-14.4.2.0-29.fc33.x86_64
libsndfile-1.0.28-13.fc33.x86_64
I am a bit surprised that change gain would be a default behavior,
definitely not what I would expect from just attempting to change the file
format.
--
Chris Caudle
What does sndfile-info show about t1w64.w64 and
t2wav.wav files? I
tried
using sox to convert a float file I had in an Ardour project directory
to
PCM, and sndfile-info reported the exact same maximum value for both.
Using the sox stat effect also displayed the same maximum and minimum
for
original and converted file as well, but sndfile-info might give you
some
insight into why sox did not seem to show the same value.
Side by side for easy comparison:
File : t1w64.w64 t2wav.wav
Length : 3840136 1920044
riff : 3840136 1920036
wave
fmt : 40 16
Format : 0x3 => WAVE_FORMAT_IEEE_FLOAT 0x1 => WAVE_FORMAT_PCM
Channels : 2 2
Sample Rate : 48000 48000
Block Align : 8 4
Bit Width : 32 16
Bytes/sec : 384000 192000
fact : 32
frames : 480000
data : 3840024
End
-----------------------------------------------------------------------
Sample Rate : 48000 48000
Frames : 480000 480000
Channels : 2 2
Format : 0x000B0006 0x00010002
Sections : 1 1
Seekable : TRUE TRUE
Duration : 00:00:10.000 00:00:10.000
Signal Max : 0.584686 (-4.66 dB) 32767 (-0.00 dB)
That last 'Signal Max' comparison does seem to confirm that
normalisation has occurred.
2:56 p.m.
On Mon, 9 Nov 2020 17:11:22 -0600 "Chris Caudle" wrote:
On Sat, November 7, 2020 1:04 am, John Murphy wrote:
sox 14.4.2-3ubuntu0.18.04.1
On Fri, 6 Nov 2020 15:19:22 -0600 "Chris
Caudle" wrote:
Signal Max : 0.584686 (-4.66 dB) 32767 (-0.00 dB)
That last 'Signal Max' comparison does seem to confirm that
normalisation has occurred.
That is different than the results on my system, even though I used the
same SoX command line you showed before. I don't know if that implies
some difference between versions of SoX, or different compile time
options, or different versions of sndfile-lib installed on my system
(Fedora 33 just for info).
sox-14.4.2.0-29.fc33.x86_64 libsndfile-1.0.28-13.fc33.x86_64
libsndfile
1.0.28-4ubuntu0.18.04.1
Not vastly different here (Mint 19.3)
I am a bit surprised that change gain would be a
default behavior,
definitely not what I would expect from just attempting to change the file
format.
Me too. Hence my misconception in the thread title. Happy to know what
was happening and I'll probably use normalisation anyway, from now on.
I'm not sure how I would find SFC_GET_NORM_FLOAT which has a page at:
http://www.mega-nerd.com/libsndfile/command.html#SFC_GET_NORM_FLOAT
Could that setting be making the difference?
--
John.
3:16 p.m.
Just wanted to say thanks again for the help with this. I've learnt:
Record levels are the same in Alsa and Jack and it was a normalisation
process which was making them look different (as well as how the levels
are shown in PavCtl are lower than in TimeMachine).
Normalisation loses nothing, but better utilises the available bit depth.
Cronjobs are easy to set up and this helps with the values:
https://crontab.guru/
------
My Bash script:
#!/bin/bash
# folder to use
a="/home/john/1tB-SSD/att/2020/"
# duration (2 hours is 7200 seconds)
d=7320
# add the date in the right format for the filename:
a+=$(date +%a%d%m.wav)
# start recording
jack_capture --daemon --channels 2 --port system:capture* -b 16 -d $d -fn $a
(I watched it make the connections in QjackCtl connections and
I even stayed up to watch it disconnect :) )
--
John.
5:42 p.m.
On Tue, Nov 10, 2020 at 6:17 AM John Murphy <rosegardener(a)freeode.co.uk>
wrote:
Normalisation loses nothing, but better utilises the available bit depth.
This is a bit misleading. The signal was recorded using whatever range was
present at the time of recording. Normalisation cannot "improve" anything,
but it does mean that the peak level is at or very close to 0 dBFS, which
for many purposes (though definitely not all) is preferable.
You would rarely want to normalize to 0dBFS before using an audio recording
in a mix, for example (except that sometimes you would :)
8:04 p.m.
On Tue, 10 Nov 2020 08:42:28 -0700 Paul Davis wrote:
On Tue, Nov 10, 2020 at 6:17 AM John Murphy
<rosegardener(a)freeode.co.uk>
wrote:
You're right, of course. I suppose all it does is move the unused part
of the dynamic range from above the peak level to below the quietest level.
Normalisation loses nothing, but better utilises the available bit depth.
This is a bit misleading. The signal was recorded using whatever range was
present at the time of recording. Normalisation cannot "improve" anything,
but it does mean that the peak level is at or very close to 0 dBFS, which
for many purposes (though definitely not all) is preferable. You would rarely want to normalize to 0dBFS before
using an audio recording
in a mix, for example (except that sometimes you would :)
Exceptions are good. 'Normalize' doesn't sound like something one would
want to do to music, but it's certainly useful to make compilations from
different sources easier to listen to.
--
John.
11 Nov
11 Nov
12:10 a.m.
On Tue, Nov 10, 2020 at 06:03:23PM +0000, John Murphy wrote:
Exceptions are good. 'Normalize' doesn't
sound like something one would
want to do to music, but it's certainly useful to make compilations from
different sources easier to listen to.
If you want a constant loudness then normalisation as discussed in this
thread (i.e. on peak level) is _not_ the way to go. You should normalize
on RMS level or a dedicated loudness metric such as EBU-R128.
--
FA
5:16 a.m.
On 11/10/20 12:10 PM, Fons Adriaensen wrote:
On Tue, Nov 10, 2020 at 06:03:23PM +0000, John Murphy
wrote:
Hmm. That's something I prefer, too. How do you do that?
Thanks.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
"My password is the last 8 digits of π."
Exceptions are good. 'Normalize'
doesn't sound like something one would
want to do to music, but it's certainly useful to make compilations from
different sources easier to listen to.
If you want a constant loudness then
normalisation as discussed in this
thread (i.e. on peak level) is _not_ the way to go. You should normalize
on RMS level or a dedicated loudness metric such as EBU-R128.
11 a.m.
On Tue, Nov 10, 2020 at 05:16:29PM -1000, david wrote:
On 11/10/20 12:10 PM, Fons Adriaensen wrote:
To measure loudness of a sound file, use ebur128, e.g.
ebur128 sheryl_crow-all_i_wanna_do.wav
which will print:
Integrated loudness: 7.4 LU
Loudness range: 2.8 LU
Peak level 0.3 dB
A few lines of bash can parse this and call e.g. sox with the
right arguments.
In this case, to have standard loudness you'd reduce the level by
7.4 dB. Note that this file also has inter-sample peaks above
full scale.
--
FA
If you want a constant loudness then
normalisation as discussed in this
thread (i.e. on peak level) is _not_ the way to go. You should normalize
on RMS level or a dedicated loudness metric such as EBU-R128.
Hmm. That's something I prefer, too. How do you do that?
11:01 a.m.
On Tue, 10 Nov 2020 17:16:29 -1000 david <gnome(a)hawaii.rr.com> wrote:
On 11/10/20 12:10 PM, Fons Adriaensen wrote:
"Audacity 2.1.3 or later" can "RMS Normalize". Long thread about it:
https://forum.audacityteam.org/viewtopic.php?t=95421
Haven't needed to use normalisation for decades, but it's good to
know there's a better way (than on peak) to do it.
Thanks again Fons.
--
John.
On Tue, Nov 10, 2020 at 06:03:23PM +0000, John
Murphy wrote:
Hmm. That's something I prefer, too. How do you do that?
Thanks.
Exceptions are good. 'Normalize'
doesn't sound like something one would
want to do to music, but it's certainly useful to make compilations from
different sources easier to listen to.
If you want a constant loudness then
normalisation as discussed in this
thread (i.e. on peak level) is _not_ the way to go. You should normalize
on RMS level or a dedicated loudness metric such as EBU-R128.
10:20 p.m.
On 11/10/20 11:01 PM, John Murphy wrote:
On Tue, 10 Nov 2020 17:16:29 -1000 david
<gnome(a)hawaii.rr.com> wrote:
Yes, thanks. Once I figured out how to get the plugin and add it to
Audacity, it worked fine. It's not one that came prepackaged with
Audacity v2.3.2 that I have here.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
"My password is the last 8 digits of π."
On 11/10/20 12:10 PM, Fons Adriaensen wrote:
"Audacity 2.1.3 or later" can "RMS Normalize". Long thread
about it:
https://forum.audacityteam.org/viewtopic.php?t=95421
Haven't needed to use normalisation for decades, but it's good to
know there's a better way (than on peak) to do it.
Thanks again Fons. On Tue, Nov 10, 2020 at 06:03:23PM +0000, John
Murphy wrote:
Hmm. That's something I prefer, too. How do you do that?
Thanks.
Exceptions are good. 'Normalize'
doesn't sound like something one would
want to do to music, but it's certainly useful to make compilations from
different sources easier to listen to.
If you want a constant loudness then
normalisation as discussed in this
thread (i.e. on peak level) is _not_ the way to go. You should normalize
on RMS level or a dedicated loudness metric such as EBU-R128.
6 Nov
6 Nov
12:26 p.m.
On Thu, Nov 05, 2020 at 10:38:39PM +0000, John Murphy wrote:
Good point. It's mainly that the level will just
look wrong in the
visual editor I use.
With audio, what matters is how it sounds, not how it looks :-)
Visual representations of audio signals can be very misleading.
A good editor (e.g. Ardour) will offer a logarithmic waveform
display.
--
FA
1467
days inactive
1473
days old
linux-audio-user@lists.linuxaudio.org
26 comments
7 participants
participants (7)
-
Chris Caudle -
david -
Fons Adriaensen -
John Murphy -
Paul Davis -
Tim E. Real -
Will Godfrey