Differences recording to OGG and WAV and how to fix this

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Differences recording to OGG and WAV and how to fix this

Pander
Hi all,

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

The range used in the WAV is what I want and also get via other software
but it has these horzontal stripes (also for 32 bit). Sometimes I have a
buffer over-run but these do not correlate with when the lines appear.
These appear far more often.

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

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

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

Thanks,

Pander

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Pander
On 05/13/2015 06:15 PM, Pander wrote:

> Hi all,
>
> 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
>
> The range used in the WAV is what I want and also get via other software
> but it has these horzontal stripes (also for 32 bit). Sometimes I have a
> buffer over-run but these do not correlate with when the lines appear.
> These appear far more often.
>
> However, differences with ulaw are minimal between these two formats:
> https://i.imgur.com/5GlszUo.png WAV
> https://i.imgur.com/e89w9Km.png OGG

Ah, also signed-integer and ulaw are showing vertical stripes.

>
> How do I get rid of the veritcal lines when recoding WAV?
>
> How can I get the OGG recording improve use of range?
>
> Thanks,
>
> Pander
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sox-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sox-users
>


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Fmiser
In reply to this post by Pander
> Pander 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

It seems odd that you are specifying a compression quality
for a .wav file.

> 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

A spectrogram is a "picture" of the sound.  If the two
recordings sound different, the spectrograms will also be
different - by as much as the sound is different.

>From what I can see of the spectrograms, they don't look to
me like they are the same audio.  The .wav file has a higher
level, and has broadband pulses.  Maybe something like a hand
clap, or wind noise at the mic.

The .ogg file is quieter, and there is a steady tone from 80
to 180 seconds - but at a different frequency than the one
visible in the .wav.

I'm not sure what your goal is for the spectrograms, but if
you are wanting to see the difference between encodings, or
other processing, it usually works better to start with an
audio file rather than a microphone recording so there won't
be a difference in the source - only in the process.

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

By getting rid of the sound that created them?
 
> How can I get the OGG recording improve use of range?

Maybe by normalizing?

Another oddity I see is you are recording with a sampling
rate of 48 kHz - but the spectrograms display 0 Hz to 180
Hz.  So apparently there is some other processing beyond what
you have listed.  Could the difference in signal level be a
consequence of this other processing?  Or could this
processing have an artifact that is creating broadband pulses?

I'm doing a lot of guessing and speculating!  *smiles*

-- f

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Pander
On 05/14/2015 07:52 AM, fmiser wrote:

>> Pander 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
>
> It seems odd that you are specifying a compression quality
> for a .wav file.

That is an omission. When not using this, it gives the same result.

>
>> 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
>
> A spectrogram is a "picture" of the sound.  If the two
> recordings sound different, the spectrograms will also be
> different - by as much as the sound is different.
>

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

>>From what I can see of the spectrograms, they don't look to
> me like they are the same audio.  The .wav file has a higher
> level, and has broadband pulses.  Maybe something like a hand
> clap, or wind noise at the mic.
>

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

> The .ogg file is quieter, and there is a steady tone from 80
> to 180 seconds - but at a different frequency than the one
> visible in the .wav.
>
> I'm not sure what your goal is for the spectrograms, but if
> you are wanting to see the difference between encodings, or
> other processing, it usually works better to start with an
> audio file rather than a microphone recording so there won't
> be a difference in the source - only in the process.

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.

>
>> How do I get rid of the veritcal lines when recoding WAV?
>
> By getting rid of the sound that created them?
>  

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

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

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

>
> Another oddity I see is you are recording with a sampling
> rate of 48 kHz - but the spectrograms display 0 Hz to 180
> Hz.  So apparently there is some other processing beyond what
> you have listed.  Could the difference in signal level be a
> consequence of this other processing?  Or could this
> processing have an artifact that is creating broadband pulses?

I look only at a part of the spectrum with

sox test.wav -n remix - rate 375 spectrogram

>
> I'm doing a lot of guessing and speculating!  *smiles*

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.

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. Hence, I
tried using explicit encoding and also OGG format without compression
for comparison.

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

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

>
> -- f
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sox-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sox-users
>


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Fmiser
> > fmiser wrote:
> >
> > From what I can see of the spectrograms, they don't look
> > to me like they are the same audio.  The .wav file has a
> > higher level, and has broadband pulses.  Maybe something
> > like a hand clap, or wind noise at the mic.

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

When you playback the files, can you hear the difference?  That is, can you hear what we see in the spectrogram?

> 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.

Maybe.  GSM is certainly not what I would use as a format for
sound analysis.

> > Another oddity I see is you are recording with a sampling
> > rate of 48 kHz - but the spectrograms display 0 Hz to 180
> > Hz.  So apparently there is some other processing beyond
> > what you have listed.  Could the difference in signal
> > level be a consequence of this other processing?  Or
> > could this processing have an artifact that is creating
> > broadband pulses?
>
> I look only at a part of the spectrum with
>
> sox test.wav -n remix - rate 375 spectrogram

> 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
>
> In other words, for SPL usage and spectrum analysis (no
> compression/reduction required), what is the best format to
> use?

Probably not GSM!  I don't know much about it, but it looks
like GSM is one of the lossy formats.

Lossless formats would be any of the PCM files - like .wav,
.aiff and loss-less encoding like flac.

Excerpts from SoX man page:

Accuracy
       Many file formats that compress audio discard some of
       the audio signal information whilst doing
       so. Converting to such a format and then converting
       back again will not produce an exact copy of the
       original audio.  This is the case for many formats used
       in telephony (e.g. A-law, GSM) where low signal
       bandwidth is more important than high audio fidelity,
       and for many formats used in portable music players
       (e.g.  MP3, Vorbis) where adequate fidelity can be
       retained even with the large compression ratios that
       are needed to make portable players practical.

gsm-full-rate
       GSM is currently used for the vast majority of the
       world's digital wireless telephone calls.  It utilises
       several audio formats with different bit-rates and
       associated speech quality.  SoX has support for GSM's
       original 13kbps `Full Rate' audio format.  It is
       usually CPU-intensive to work with GSM audio.

Another tool I like using for sound analysis is baudline, a
linux-only free-to-use program that does FFT and spectrum
display realtime or from a file.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Cory Nelson
In reply to this post by Pander
On Thu, May 14, 2015 at 1:05 PM, Pander <[hidden email]> wrote:

>
> On 05/14/2015 07:52 AM, fmiser wrote:
> > A spectrogram is a "picture" of the sound.  If the two
> > recordings sound different, the spectrograms will also be
> > different - by as much as the sound is different.
> >
>
> They are indeed recordings of different moment but under the same quiet
> conditions.
>
> ..
>
> Nope. I have a sound measuring setup and these broadband verticalines
> show up many times without a clear reason.
>
> ..
>
> 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.

The biggest variable here is that you're recording each time. Step one
is to remove that variable. Record once to a WAV, convert the WAV to
Vorbis, and compare those files.

If you're still seeing the issue after that, upload the WAV and give
the commands you're using to transcode to Vorbis.

WAV and Vorbis encoding identical audio should not result in markedly
different spectrograms. Assuming the Vorbis has a high enough bitrate,
the biggest difference you'd see is all high frequencies getting cut
off.

--
Cory Nelson
http://int64.org

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Pander
In reply to this post by Pander
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. 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. So first things first.

1) rec

On RPi I use

$ rec --version
rec:      SoX v14.4.0
$ arecord --version
arecord: version 1.0.25 by Jaroslav Kysela <[hidden email]>

$ arecord -L|grep =|grep -v ^surround|grep -v ^front|grep -v
^iec958|grep -v PCH
default:CARD=U18dB
sysdefault:CARD=U18dB

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: U18dB [Umik-1  Gain: 18dB], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

So card 1 and device 0 result in hw:1,0 in:

$ export AUDIODEV=hw:1,0
$ export AUDIODRIVER=alsa
$ rec -q -r 48000 -c 1 -b 24 test.wav trim 0 60
rec WARN formats: can't set 1 channels; using 2

and that records. :) Note, one *must* set AUDIODRIVER to alsa

$ 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!



On my laptop I use

$ rec --version
rec:      SoX v14.4.1
$ arecord --version
arecord: version 1.0.28 by Jaroslav Kysela <[hidden email]>

$ 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

and that records. :) Note, *no* need to set AUDIODRIVER to alsa

$ 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!

Where are these differences coming from???

Is alsamixer on RPi or laptop cause of this?
Is audio sound service of Ubuntu making the levels higher?
I don't think any of this has to do with this as previously my RPi also
was able to create these brighter spectrograms, but of course something
like this could be the cause. Any ideas how to verify that?



2) arecord

On my RPi I use

$ arecord -c 1 -f S24_LE -r 48000 -d 60 test-d.wav
arecord: main:682: audio open error: No such file or directory

So I refer to on of these devices lised above

$ arecord -D sysdefault:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav
or
$ arecord -D default:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav

and get

$ soxi test.wav

Input File     : 'test.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 24-bit
Duration       : 00:01:20.00 = 3840000 samples ~ 6000 CDDA sectors
File Size      : 11.5M
Bit Rate       : 1.15M
Sample Encoding: 24-bit Signed Integer PCM

That is 25% more data than rec produces. The spectrogram is however
completely empty (also in audacity). How is this possible?



On my laptop I set the external microphone in GNOME audio manager
settings as default (is at that moment also default for Audacity) and I
use also the devices listed above

$ arecord -D plughw:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav
arecord: main:722: audio open error: Device or resource busy

$ arecord -D hw:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav
arecord: main:722: audio open error: Device or resource busy

$ arecord -D dsnoop:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:722: audio open error: Device or resource busy

$ arecord -D dmix:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav
ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports
only playback stream
arecord: main:722: audio open error: Invalid argument

$ arecord -D sysdefault:CARD=U18dB -c 1 -f S24_LE -r 48000 -d 60 test.wav
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:722: audio open error: Device or resource busy

and if I run it without -D it goes into an endless loop and creates only
a 44 byte file

$ file test.wav
test.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 24 bit,
mono 48000 Hz

With older version of Ubuntu I was able to use arecord. How can I use
arecord on my RPi and laptop again? Or is it far better to stick with
rec on both types of devices?



3) In response of the replies that already were made to this thread:

Some additional testing on RPi with 16 bit:

$ rec -q -r 48000 -c 1 -b 16 test.wav trim 0 60
rec WARN alsa: can't encode 16-bit Signed Integer PCM
rec WARN formats: can't set 1 channels; using 2
$ soxi test.wav

Input File     : 'test.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 16-bit
Duration       : 00:00:05.63 = 270336 samples ~ 422.4 CDDA sectors
File Size      : 541k
Bit Rate       : 768k
Sample Encoding: 16-bit Signed Integer PCM

spectrogram looks also dark:
https://i.imgur.com/Ak6Geg3.png
while same test on laptop is bright again:
https://i.imgur.com/VaG8dVk.png

As a workaround I can rec with gain on the RPi but am still wondering
where that difference in gain/attenuation is coming from.

Some additional testing on RPi with gsm-full-rate (16 bit implied):

$ rec -q -r 48000 -c 1 -e gsm-full-rate test.wav trim 0 60
rec WARN alsa: can't encode 16-bit GSM
rec WARN formats: can't set 1 channels; using 2
$ soxi test.wav

Input File     : 'test.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 16-bit
Duration       : 00:01:00.00 = 2880000 samples ~ 4500 CDDA sectors
File Size      : 585k
Bit Rate       : 78.0k
Sample Encoding: GSM

spectrogram looks bright: https://i.imgur.com/lVEEIPU.png but this
encoding I won't investigate further




On 05/14/2015 08:05 PM, Pander wrote:

> On 05/14/2015 07:52 AM, fmiser wrote:
>>> Pander 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
>>
>> It seems odd that you are specifying a compression quality
>> for a .wav file.
>
> That is an omission. When not using this, it gives the same result.
>
>>
>>> 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
>>
>> A spectrogram is a "picture" of the sound.  If the two
>> recordings sound different, the spectrograms will also be
>> different - by as much as the sound is different.
>>
>
> They are indeed recordings of different moment but under the same quiet
> conditions.
>
>> >From what I can see of the spectrograms, they don't look to
>> me like they are the same audio.  The .wav file has a higher
>> level, and has broadband pulses.  Maybe something like a hand
>> clap, or wind noise at the mic.
>>
>
> Nope. I have a sound measuring setup and these broadband verticalines
> show up many times without a clear reason.
>
>> The .ogg file is quieter, and there is a steady tone from 80
>> to 180 seconds - but at a different frequency than the one
>> visible in the .wav.
>>
>> I'm not sure what your goal is for the spectrograms, but if
>> you are wanting to see the difference between encodings, or
>> other processing, it usually works better to start with an
>> audio file rather than a microphone recording so there won't
>> be a difference in the source - only in the process.
>
> 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.
>
>>
>>> How do I get rid of the veritcal lines when recoding WAV?
>>
>> By getting rid of the sound that created them?
>>  
>
> Probably, but they appear even when I don't hear extremely loud noises.
>
>>> How can I get the OGG recording improve use of range?
>>
>> Maybe by normalizing?
>
> I use the recordings with a calibrated system so I am not allowed to do
> normalisations that alter the sound level.
>
>>
>> Another oddity I see is you are recording with a sampling
>> rate of 48 kHz - but the spectrograms display 0 Hz to 180
>> Hz.  So apparently there is some other processing beyond what
>> you have listed.  Could the difference in signal level be a
>> consequence of this other processing?  Or could this
>> processing have an artifact that is creating broadband pulses?
>
> I look only at a part of the spectrum with
>
> sox test.wav -n remix - rate 375 spectrogram
>
>>
>> I'm doing a lot of guessing and speculating!  *smiles*
>
> 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.
>
> 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. Hence, I
> tried using explicit encoding and also OGG format without compression
> for comparison.
>
> 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
>
> In other words, for SPL usage and spectrum analysis (no
> compression/reduction required), what is the best format to use?
>
>>
>> -- f
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Sox-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sox-users
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sox-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sox-users
>


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Jan Stary
On May 13 18:15:00, [hidden email] 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, [hidden email] 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 <[hidden email]>
>
> $ 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.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Differences recording to OGG and WAV and how to fix this

Jan Stary
> 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

Sorry:

   $ sox file.wav -n 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

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


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

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users