![]() |
| 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. |
|
|||||||
|
|
|
Thread Tools | Display Modes |
|
#11
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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 | |
|
|
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 |