Re: [SoX-users] Differences recording to OGG and WAV and how to fix this

[Jan S. <ha...@st...>]

On May 13 18:15:00, pa...@us... wrote:
> I use the same microphone (USB 24 bit 48kHz) to do the following recordings:
> 
> rec -q -r 48000 -c 1 -b 24 -e gsm-full-rate --buffer 16384 -C 10
> test.wav trim 0 360
> rec -q -r 48000 -c 1 -b 24 -e gsm-full-rate --buffer 16384 -C 10
> test.ogg trim 0 360
> 
> But the result in spectrograms is are very different, see:
> https://i.imgur.com/fTMvDuK.png WAV
> https://i.imgur.com/z6YUcxF.png OGG

So the wav and the ogg are two different recordings?
Of course they are gonna have different spectrograms.

> The range used in the WAV is what I want and also get via other software

The range used in the spectrogram of the wav
and in the spectrogram of the ogg is the same,
namely, 0-180 Hz.

> but it has these horzontal stripes (also for 32 bit).

These stripes are in the spectrogram
because the sound is present in the audio.

> However, differences with ulaw are minimal between these two formats:
> https://i.imgur.com/5GlszUo.png WAV
> https://i.imgur.com/e89w9Km.png OGG

So these are yet another two recordings.
That's another two spectrograms of course.

> How do I get rid of the veritcal lines when recoding WAV?

You don't "get rid" of them.
They are in the spectrogram, because the sound is there.

> How can I get the OGG recording improve use of range?

First of all,

 $ rec -r 48000 -c 1 -b 24 -e gsm-full-rate file.ogg trim 0 10
 rec WARN formats: vorbis can't encode GSM
 rec WARN formats: vorbis can't encode to 24-bit

You are using parameters which the vorbis encoding does not support.

> They are indeed recordings of different moment
> but under the same quiet conditions.

That has nothing to do with it. They are two different recordings
of two different audio signals (you are not recording zero silence).
So they have two different spectrograms.

> Nope. I have a sound measuring setup and these broadband verticalines
> show up many times without a clear reason.

The reason is there is a broadband sound recorded in the audio,
at about 140 and 160 and 280 seconds, at a level of about -70dB,
as your spectrograms indicate.

> I make many recordings under the same conditions and these differences
> are huge. I am looking for the reason. Perhaps it is the file format.

It's not the file format; it's two different recordings
of two different audio signals.

> Probably, but they appear even when I don't hear extremely loud noises.

-70dB is not extremely loud.

> >> How can I get the OGG recording improve use of range?

What range? The dynamical range of the near-silence you are recording?
The frequency spectrum of the noise you are recording?

> I use the recordings with a calibrated system so I am not allowed to do
> normalisations that alter the sound level.

Normalizing an audio file has nothing to do with your "calibrated system".
Depending on what you mean by the "range", it also has nothing to do
with your nonproblem.

> sox test.wav -n remix - rate 375 spectrogram

If you are limiting rate to 375, the resulting signal
will not contain frequencuies above 188 Hz,
so they are not in the spectrogram.

> In short, I used to record with rec with an identical command on a
> Raspberry Pi and got the spectrogram with more bright colors so to say.

That's yet another recording of yet another signal
with yet another spectrogram. The Raspberry has nothing to do with it.

> On a new Raspberry Pi with also Raspbian, I get now a spectrogram with
> darker colors. I am trying to figure out what is happening.

You are recording many different audio signals,
and they have different spectrograms of course.

Record a signal into a wav file and create the spectrogram:

  $ rec -c file.wav 0 10
  $ sox file.wav spectrogram -o wav.png

Now convert that file to an ogg and create its spectrogram:

  $ sox file.wav file.ogg
  $ sox file.ogg spectrogram -o ogg.png

Are the two spectrograms identical? Yes, nearly identical,
except the ogg format cuts away the very high frequencies.

> Hence, I
> tried using explicit encoding and also OGG format without compression
> for comparison.

Encoding, format, and copression have nothing to do with it,
unless they change the audio signal significantly.

> What is the default encoding that is used when none is specified and you
> record to WAV? Is that signed-integer or gsm-full-rate

Look and see:

 $ rec file.wav
 Input File     : 'default' (sndio)
 Channels       : 2
 Sample Rate    : 48000
 Precision      : 16-bit
 Sample Encoding: 16-bit Signed Integer PCM

But that has nothing to do with your question.

> In other words, for SPL usage and spectrum analysis (no
> compression/reduction required), what is the best format to use?

Probably WAV or even RAW. Surely not GSM.
(What "spectrum analysis"?)


On May 14 23:51:37, pa...@us... wrote:
> On WAV only to elaborate a bit more: I have a laptop with latest Ubuntu
> that can record only with audacity and arecord and several Raspberry Pis
> with latest Raspbian that can record with only rec.
> 
> I get *differences* in the level of the recordings when I use the
> defaults from all applications and I even found a difference from one
> version on RPi with another.

You are recoring different signals
(on different systems and different hardware, too).
Of course they are different.

> To investigate this and to consolidate
> recordings amongst these applications I would like to find out which are
> defaults in encoding and level and how do I use explicit certain options
> to consolidate those differences.
> 
> 1) rec

If you record to WAV, the default encoding will be PCM signed integer.
rec(1) will not set any levels; that's what you do with your mixer.

> $ rec -q -r 48000 -c 1 -b 24 test.wav trim 0 60
> rec WARN formats: can't set 1 channels; using 2
> $ soxi test.wav
> Input File     : 'test.wav'
> Channels       : 1
> Sample Rate    : 48000
> Precision      : 24-bit
> Duration       : 00:01:00.00 = 2880000 samples ~ 4500 CDDA sectors
> File Size      : 8.64M
> Bit Rate       : 1.15M
> Sample Encoding: 24-bit Signed Integer PCM
> 
> Spectrogram full:
> https://i.imgur.com/SZ5Aur4.png
> Spectrogram low frequency:
> https://i.imgur.com/4cYLsj0.png
> 
> The spectrograms look dark!

Because you have recorded near-silence, or a low-freuency hum.

> On my laptop I use
> $ rec --version
> rec:      SoX v14.4.1
> $ arecord --version
> arecord: version 1.0.28 by Jaroslav Kysela <pe...@pe...>
> 
> $ arecord -L|grep =|grep -v ^surround|grep -v ^front|grep -v
> ^iec958|grep -v PCH
> sysdefault:CARD=U18dB
> dmix:CARD=U18dB,DEV=0
> dsnoop:CARD=U18dB,DEV=0
> hw:CARD=U18dB,DEV=0
> plughw:CARD=U18dB,DEV=0
> 
> $ arecord -l
> **** List of CAPTURE Hardware Devices ****
> card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 1: U18dB [Umik-1  Gain: 18dB], device 0: USB Audio [USB Audio]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> 
> $ export AUDIODEV=hw:1,0
> $ rec -q -r 48000 -c 1 -b 24 test.wav trim 0 60
> rec WARN formats: can't set 1 channels; using 2
> 
> $ soxi test.wav
> 
> Input File     : 'test.wav'
> Channels       : 1
> Sample Rate    : 48000
> Precision      : 24-bit
> Duration       : 00:01:00.00 = 2880000 samples ~ 4500 CDDA sectors
> File Size      : 8.64M
> Bit Rate       : 1.15M
> Sample Encoding: 24-bit Signed Integer PCM
> 
> Spectrogram full:
> https://i.imgur.com/ap2f6qc.png
> Spectrogram low frequency:
> https://i.imgur.com/XYFYIhp.png
> The spectrograms look bright!

Yes. You have recorded something else now, on a different hardware,
and on a different system. This time there is more low-frequency hum.

> Where are these differences coming from???

They are different audio signals.

> Is alsamixer on RPi or laptop cause of this?

No.

> Is audio sound service of Ubuntu making the levels higher?

Possibly. That has nothing do do with it.

> 2) arecord

OK, the dead horse is probably beaten enough by now.
You recorded different sounds, and you ask how come they are different.