A Home cinema forum. HomeCinemaBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HomeCinemaBanter forum » Home cinema newsgroups » UK digital tv
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Linux or Windows utility to report RMS values in *.WAV files?



 
 
Thread Tools Display Modes
  #11  
Old August 21st 11, 02:04 PM posted to uk.rec.audio;,uk.tech.digital-tv
Java Jive[_3_]
external usenet poster
 
Posts: 1,892
Default Linux or Windows utility to report RMS values in *.WAV files?

On Sun, 21 Aug 2011 12:07:26 +0100, Jim Lesurf
wrote:

In article , David Woolley
wrote:

Why do you want RMS? I would have thought peak was a better measure.


Because then I would be measuring the level of the scratches!

It's quite difficult to set levels for the recorded content when the
vinyls are quite badly scratched, as many of them are. The only
reason I'm interested in preserving them is because most of these
recordings are just not available by any other means any more.

I think this depends on what you need to know. Peak is good for checking
for clipping problems. rms tends to be closer to the perceived sound level.


Yes, I just want a ball-park figure to give an idea of how many are
likely to need rerecording because the original level was too low.

If you really want RMS, use sox to convert the file to raw signed 16 bit
samples, then write a program to read the stream and compute RMS.


Tanks for that suggestion ...

It is easy enough to read normal lpcm wave files. No need to convert to raw
data files. e.g. as I've pointed out in another reply, you can use WAVstats
from my software webpage for a normal wav file. That will give the stats
for peak and form factor directly - both as time series and histograms. You
can then easily turn that into rms if needed.

Alternatively, hack WAVstats to give rms if that is what is needed. The
source code is provided.


Thanks David, Jim, and everyone else who has made suggestions.

After I posted late last night, I found something called WaveGain, and
left it running overnight analysing all the files. However, it's not
very well documented, and as yeat I'm not quite sure how to interpret
the results. I presume that the Gain and Scale figures are a measure
of the digital amplification that would be required to bring the files
up to a 'normal' level, but what a 'normal' level would meain I'm not
quite sure.

It produces output like the following (which I fear this is going to
look a mess because of line-wrap - probably best to copy'n'paste it
into something that has a fixed font, like Notepad):

Analyzing...

Gain | Peak | Scale | New Peak |Left DC|Right DC| Track
| | | |Offset | Offset |
--------------------------------------------------------------
+3.96 dB | 20758 | 1.58 | 32765 | -95 | -160 | Vin Garbutt
- King Gooden - Side 1 (unwashed).wav
1.578420

WaveGain Processing completed normally

Analyzing...

Gain | Peak | Scale | New Peak |Left DC|Right DC| Track
| | | |Offset | Offset |
--------------------------------------------------------------
+6.68 dB | 15184 | 2.16 | 32765 | -95 | -160 | Vin Garbutt
- King Gooden - Side 2 (unwashed).wav
2.157919

WaveGain Processing completed normally
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
  #12  
Old August 21st 11, 04:39 PM posted to uk.rec.audio;,uk.tech.digital-tv
Jim Lesurf[_2_]
external usenet poster
 
Posts: 4,567
Default Linux or Windows utility to report RMS values in *.WAV files?

In article , Java Jive
wrote:
On Sun, 21 Aug 2011 12:07:26 +0100, Jim Lesurf
wrote:

In article , David Woolley
wrote:

Why do you want RMS? I would have thought peak was a better measure.


Because then I would be measuring the level of the scratches!


It's quite difficult to set levels for the recorded content when the
vinyls are quite badly scratched, as many of them are.


The 'best' choice for you will then depend on if you want to avoid clipping
the 'clicks' or not. I suspect you want to also monitor the crest factor.
If the scratches are really 'sharp' then this will pick up the scratches,
although backscanning may be better if the cartridge is ringing or the
preamp is saturating.

One of the reasons I included monitoring crest factor in my own prog was to
show when there were any fast transients or clipping as these hit the crest
factor.


Yes, I just want a ball-park figure to give an idea of how many are
likely to need rerecording because the original level was too low.


The problem is that if you scale up the levels you may clip the clicks.
Does that matter or not?


After I posted late last night, I found something called WaveGain, and
left it running overnight analysing all the files. However, it's not
very well documented, and as yeat I'm not quite sure how to interpret
the results. I presume that the Gain and Scale figures are a measure of
the digital amplification that would be required to bring the files up
to a 'normal' level, but what a 'normal' level would meain I'm not
quite sure.


Can't comment. But I'd be wary without testing such a program with 'known'
waveforms, etc. 'Normalised' should in principle mean scaling so that the
biggest sample value reaches just 0dBFS. That way all samples remain in
range. However with clicks that might be too quiet for your taste if you
don't mind clipping loud clicks. If they are 'normalising' the rms then you
may get a lot of clipping if the program doesn't work sensibly!

Personally I prefer to DIY my own progs for things like this so I can make
my own mistakes! FWIW I have in the past been quite alarmed/depressed by
some of the comments in Linux mags about how to 'normalise' or compress
music. To me it seemed like a recipie for trouble.

FWIW2 My WAV stats prog also gives you the peak sample value for the file.
So would tell you what to scale by if you want 0dBFS 'normalisation'.
However again I'd always go for -3dBFS to avoid intersample problems with
any following DAC or conversions.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

  #13  
Old August 21st 11, 04:55 PM posted to uk.rec.audio;,uk.tech.digital-tv
J G Miller[_4_]
external usenet poster
 
Posts: 5,296
Default Linux or Windows utility to report RMS values in *.WAV files?

On Saturday, August 20th, 2011 at 19:52:06h +0100, Java Jive wrote:

Is there such a thing?


Would you not get a more informed answer if you asked
at the Hydrogen Audio Forums?

http://www.hydrogenaudio.ORG/
  #14  
Old August 21st 11, 05:44 PM posted to uk.rec.audio,uk.tech.digital-tv
Jim Lesurf[_2_]
external usenet poster
 
Posts: 4,567
Default Linux or Windows utility to report RMS values in *.WAV files?

In article , Java Jive
wrote:
Dodgy cartridge connections in the arm of the old turntable. It's
happens quite a lot but I usually notice it straightaway, remove the
cartridge holder from the arm, check the contacts, and replace it -
nine times out of ten that fixes it.


Some comments/questions...

If that happens so often than I'd also be worried that the contact is
non-ohmic at other times and so adding distortion.

Do you not clean the contacts with a non-residue cleaner?

If it keeps happening then it might be worth trying a new headshell.
Although of course the problem may be in the arm socket, so that might noit
help.

Also, to detect dropouts on material you aren't listening to during
recording it might be useful to

a) Look at plots of level vs time.

b) Look at the histogram for a cluster of low level readings.

Although that assumes the noise level falls when the connection fails,
which may not be the case.

If you have lots more to do, then either a change of player or some
software to detect bursts of low level might be useful. But I have no idea
how much time or effort you have to devote to this.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

  #15  
Old August 29th 11, 01:20 AM posted to uk.rec.audio,uk.tech.digital-tv
Johny B Good
external usenet poster
 
Posts: 72
Default Linux or Windows utility to report RMS values in *.WAV files?

On Sun, 21 Aug 2011 11:58:10 +0100, Jim Lesurf
wrote:

====snip====


FWIW I've seen examples of files that were clearly clipped or madly
compressed, but to a level well below 0dBFS. It would be hard for an
automated system to tell if this was happening, but to the human eyeball
the plots make it clear - as do the ears! :-)


I'm guessing at clipping level of around -3.5db FSD. It's a very common
failing when a PCI or on-board sound card has been used to digitise
analogue sources from the line in socket.

--
Regards JB Good
  #16  
Old August 29th 11, 02:11 AM posted to uk.rec.audio;,uk.tech.digital-tv
Johny B Good
external usenet poster
 
Posts: 72
Default Linux or Windows utility to report RMS values in *.WAV files?

On Sat, 20 Aug 2011 19:52:06 +0100, Java Jive
wrote:

Is there such a thing?

I have 256 *.wav files from recording my vinyls. Looking through
them, it is clear that there has been channel drop-out on at least
one, and that others look as they may have been recorded at too lower
a level. I would like to run a batch process that will report the RMS
on these files to give me an idea which and how many may need to be
re-digitised.


I think it's safe to say that you weren't using Cool Edit Pro to digitise
your vinyl collection. This is what I use to digitise my analogue
collection on a PC with an old enough MoBo to still have at least one ISA
slot to accommodate my SoundBlaster 64 Gold sound card.

If you're using a PCI soundcard or on-board sound chip, it's odds on that
you'll never see recording levels higher than about -3.5db FSD without
severe clipping distortion.

The sound chips used on PCI adapters (and for on-board) have a jumperable
option to desensitise the line input by 6db (presumably to reduce the
noise floor in the ADC by that amount). Unfortunately, the "whole world
and their dog" soundcard and MoBo manufacturers based their products on
the reference design provided by the sound chip manufacturer and hard
jumpered the chip for the 6db desensing option, neglecting the fact that
the line in buffer amp would clip at around the -3.5db FSD mark due to the
insufficient bias voltage provided by the 5v rail.

The older ISA cards seem to power their Line input buffer amp from the
12v rail thus neatly precluding the possibility of such a stupid design
error (either that or else the sound card makers knew enough to not
implement such an error of choice in the ADC sensitivity level).

You may well see distortion of your low level recordings if they peak as
high as -3.5db FSD in which case, the damage has already been done. You
can either re-digitise them again at a low enough level to avoid exceeding
the -4db FSD mark if you still have access to the original vinyl or else
accept the clipping and normalise them anyway.

An important issue with vinyl is the level of the unwanted pops and
clicks which you need to examine before applying normalisation since a
single loud pop or click can easily exceed the peak level of the musical
content. Whenever I look at my raw recordings, this is the priority before
attempting to normalise the recording.

Such recorded pops and clicks are quite often the reason for the clip
indicator to be latched, a very nice feature of Cool Edit Pro's
recording/playback graph (but it does rely on the sound card allowing FSD
values up the 0db mark to be captured).

Once all the gross clicks or pops have been filtered out, I then
normalise the whole track with reasonable confidence that I'm not about to
seriously skew the left/right balance.

With Cool Edit Pro, it scans the track and then displays the amount of
lift required on each channel to normalise to 0db FSD. At this point, you
can either change the amplification factor from that discovered in the
scan or else cancel the operation. IOW, you can use this feature simply to
report the maximum peak levels attained on each channel.



I have Windows programs that will batch process files to, say,
normalise the sound to peak at 0dB, or have a given RMS, but nothing
that will report the current RMS values without doing anything.

Any suggestions?


Er, try Cool Edit Pro (or other recording software that has that same
normalisation feature of allowing you to preview the calculated
amplification before applying it)?

--
Regards JB Good
  #17  
Old August 29th 11, 04:12 AM posted to uk.rec.audio;,uk.tech.digital-tv
Johny B Good
external usenet poster
 
Posts: 72
Default Linux or Windows utility to report RMS values in *.WAV files?

On Sun, 21 Aug 2011 13:04:07 +0100, Java Jive
wrote:

On Sun, 21 Aug 2011 12:07:26 +0100, Jim Lesurf
wrote:

In article , David Woolley
wrote:

Why do you want RMS? I would have thought peak was a better measure.


Because then I would be measuring the level of the scratches!


You need to identify and attenuate, if not completely eliminate them,
before you attempt to normalise. This should be a fairly trivial exercise
with a halfway decent sound recording editing program (at this stage,
you're simply looking for the monster pops and crackles which should be
quite visible in the edit window).

Even if rms is important for getting the perceived left/right channel
balance correct, it's still the peak levels that are paramount to the
normalisation process. You can always tweak the loud sounding channel to a
quieter level if you feel that such an adjustment is required post peak
level normalisation.

It's very rare that such an adjustment would be required after the
recording has been normalised on peak levels, especially if the recording
is a whole side of a vinyl LP record. If such a need arises, it would
rather suggest a preponderance of musical instruments with very high crest
factors having been panned to the left or right channel in the original
recording, a situation usually avoided by most recording studios.


It's quite difficult to set levels for the recorded content when the
vinyls are quite badly scratched, as many of them are. The only
reason I'm interested in preserving them is because most of these
recordings are just not available by any other means any more.


As I've mentioned in an earlier posting, you need to deal with such
transient blemishes before you even consider applying any normalisation. I
would advise against letting the automatic click and pop removal tool
loose on the whole recording since they can totally destroy the sound of
certain instruments, notably brass, as well as fail to completely
eliminate all the unwanted transients.


I think this depends on what you need to know. Peak is good for checking
for clipping problems. rms tends to be closer to the perceived sound
level.


Yes, I just want a ball-park figure to give an idea of how many are
likely to need rerecording because the original level was too low.

If you really want RMS, use sox to convert the file to raw signed 16

bit
samples, then write a program to read the stream and compute RMS.


Tanks for that suggestion ...


Imho, I think you're barking up the wrong tree by even considering rms
values. By far, the more important values to consider are the peak values.
RMS values are useful for power distribution systems (50 and 60 Hertz
waveforms) and to a lesser extent in music with non percussive instruments
such as organs (both church and electronic) which can sustain notes at a
constant amplitude and pose an overheating risk in analogue amps and
speaker voice coils.


It is easy enough to read normal lpcm wave files. No need to convert to
raw
data files. e.g. as I've pointed out in another reply, you can use
WAVstats
from my software webpage for a normal wav file. That will give the stats
for peak and form factor directly - both as time series and histograms.
You
can then easily turn that into rms if needed.

Alternatively, hack WAVstats to give rms if that is what is needed. The
source code is provided.


Thanks David, Jim, and everyone else who has made suggestions.

After I posted late last night, I found something called WaveGain, and
left it running overnight analysing all the files. However, it's not
very well documented, and as yeat I'm not quite sure how to interpret
the results. I presume that the Gain and Scale figures are a measure
of the digital amplification that would be required to bring the files
up to a 'normal' level, but what a 'normal' level would meain I'm not
quite sure.


You're correct in interpreting the gain figure as being the 'required
gain to normalise to peak level'. The 'normal' level is the maximum
amplitude value that can be digitally represented in each 16 bit sample
and is usually refered to as the FSD value (Full Scale Deflection, a term
stolen from the domain of analogue metering).


It produces output like the following (which I fear this is going to
look a mess because of line-wrap - probably best to copy'n'paste it
into something that has a fixed font, like Notepad):

Analyzing...

Gain | Peak | Scale | New Peak |Left DC|Right DC| Track
| | | |Offset | Offset |
--------------------------------------------------------------
+3.96 dB | 20758 | 1.58 | 32765 | -95 | -160 | Vin Garbutt
- King Gooden - Side 1 (unwashed).wav
1.578420

WaveGain Processing completed normally

Analyzing...

Gain | Peak | Scale | New Peak |Left DC|Right DC| Track
| | | |Offset | Offset |
--------------------------------------------------------------
+6.68 dB | 15184 | 2.16 | 32765 | -95 | -160 | Vin Garbutt
- King Gooden - Side 2 (unwashed).wav
2.157919

WaveGain Processing completed normally


If those results are of the raw recordings before any click/pop removal
has been applied, then they're almost totally useless for your purpose.

I'm afraid to say, if you want to avoid unnecessary work re- digitising
your analogue collection, a batch process of your current collection isn't
going to cut it.

The only option is to use a decent sound file editor and examine the
recording by eyeball and ear (when you have some 15 to 30 minute's worth
showing in the edit window, not every spike will be a click or pop. You'll
need to zoom in on every likely candidate and audition them to be sure.)

With some 256 recordings to deal with, this is a rather daunting task but
it's really the only effective way to deal with the problem (both unwanted
pops and clicks as well as the recording levels). With practice and a
decent editor, you should be able to remove the gross clicks and pops
which interfere with the peak level analysis in a matter of minutes per
track, say 10 to 15 minutes per LP recording.

Incidently, I noticed the DC offsets (which will almost certainly be
expressed in mV) which you'll also need to cancel out when you're finally
ready to apply normalisation.

The DC offset is an artifact of the ADC used in the sound card. The right
channel offset value looks a little on the high side suggestive of a cheap
sound card which begs the question as to what you are using to digitise
your analogue source. I've assumed you're using the built in sound on your
PC (whether a separate PCI card or an on-board sound chip) but it could
just as well be an external adapter (firewire/usb or WHY) for all I know.

As I've previously mentioned, a PCI sound card or on-board sound chip is
very likely not going to produce levels above the -3.5db FSD mark without
gross clipping distortion. You may well find that the smallest 'required
gain' figure will never drop below 3db for any of your recordings. If that
turns out to be the case, you'll know why (and also why you'll need to
avoid recorded levels higher than -4db).


--
Regards JB Good
  #18  
Old August 29th 11, 09:52 AM posted to uk.rec.audio,uk.tech.digital-tv
Jim Lesurf[_2_]
external usenet poster
 
Posts: 4,567
Default Linux or Windows utility to report RMS values in *.WAV files?

In article [email protected], Johny B Good
wrote:
On Sun, 21 Aug 2011 11:58:10 +0100, Jim Lesurf
wrote:


====snip====



FWIW I've seen examples of files that were clearly clipped or madly
compressed, but to a level well below 0dBFS. It would be hard for an
automated system to tell if this was happening, but to the human
eyeball the plots make it clear - as do the ears! :-)


I'm guessing at clipping level of around -3.5db FSD. It's a very
common failing when a PCI or on-board sound card has been used to
digitise analogue sources from the line in socket.


Good estimate. :-)

One example (A track from a 'Franz Ferdinand' CD) has a peak at -3.52dBFS
on one channel and -3.13dBFS on the other. A histogram of the rate of
occurances of various levels has one channel sitting between -3 and -4 dBFS
for about 28 percent of the time! The shape of the distribution looks
almost like the bottom half of a squashed gaussian.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

  #19  
Old August 29th 11, 10:16 AM posted to uk.rec.audio;,uk.tech.digital-tv
Jim Lesurf[_2_]
external usenet poster
 
Posts: 4,567
Default Linux or Windows utility to report RMS values in *.WAV files?

In article [email protected], Johny B Good
wrote:
On Sat, 20 Aug 2011 19:52:06 +0100, Java Jive
wrote:



If you're using a PCI soundcard or on-board sound chip, it's odds on
that you'll never see recording levels higher than about -3.5db FSD
without severe clipping distortion.



With Cool Edit Pro, it scans the track and then displays the amount of
lift required on each channel to normalise to 0db FSD.


[Snip]

Thanks for the explanation about soundcard problems. Very interesting.
It does reinforce my jaded view of the kit computer makers tend to
flog for 'audio'. Also explains some of the problems I've seen signs
of if it is common. Depressing, but not a surprise...

FWIW I would recommend avoiding normalising up to having the max peak
reach 0dBFS. This is because you may then run into problems later with
intersample peaks needing to be above 0dBFS. This can occur with
oversampling or upsampling DACs or if you decide to convert the results to
some other format.

To see more on this, have a look at

http://www.audiomisc.co.uk/HFN/OverTheTop/OTT.html

There you can see that to be really confident you should keep peaks at
least a few dB below 0dBFS. Personally, I always try to keep peaks below
-4dBFS when recording analogue sources.

BTW If you monitor something like the BBC R3 'HD audio' stream you'll see
they keep to below about -6dBFS to give headroom for any problems.

FWIW I also use a dedicated recorder, not a soundcard. And if I think I may
want to rescale the results I'd start off with 24 bit samples to reduce
quantising effects. That said, I almost never rescale a recording. Volume
controls still exist, despite the music biz seeming to think no-one now
will ever use one. :-)

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
vmware virtualization,storage,linux,windows Training sancentre UK digital tv 0 November 15th 08 07:48 AM
Windows app to convert h264 .ts files to mpeg2 .ts files ap99 High definition TV 1 December 8th 06 06:35 PM
Which HDTV tuner and software to get for PCs (Windows & Linux)? [email protected] High definition TV 4 October 23rd 05 03:37 AM
Any Utility to Mount Tivo Drive Under Windows 2000? Will Tivo personal television 8 June 18th 05 03:09 PM
Linux decoding of TiVo2Go files? [email protected] Tivo personal television 10 May 22nd 05 02:12 AM


All times are GMT +1. The time now is 02:21 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Copyright ©2004-2021 HomeCinemaBanter.
The comments are property of their posters.