Have been trying to think creatively of a way to use a chain to evaluate a series of files to see whether the peak level exceeds 0db.
Is this at all possible?
Not that I can see. If you want just what you said (not an exact peak level), why not import all the files into one project and turn on View > Show Clipping?
Gale
Thanks for your reply Gale.
I was thinking of this more from a sort of music library validation perspective.
I would like to convert my library of several thousand .wav files into normalised flac files using a chain, and felt a clipping detection ‘report’ would be a sensible preliminary step to identify any problem files.
However, judging by the lack of comment I seem to be alone in alone in finding this attractive, so I guess there is little point in submitting a feature request.
I’ve moved this to the “Adding Features” board. Batch does not support analysis “effects” at the moment, but even it did, what are you hoping for? That Audacity should open and close all those files, and at the end come up with a text file that reports the peak level in each, the clipped ones listed first?
Gale
Right, something along those lines.
Or depending on how the internals work, a text file outputting the timestamps if any from the little window created via Analyse → Find clipping, with a 0 byte file size indicating the absence of clipping.
Thanks for your consideration.
Or perhaps this could be combined with some kind of file properties summary report, for example with peak amplitude, length, sample rate, clipping, etc.
And then the option to view the report either a) in a window or b) as a file with the report in its entirety or just individual fields.
I am sure things like this can be done at the command-line using SOX’s “stat” effect - see http://www.hydrogenaudio.org/forums/index.php?showtopic=83319 for some ideas.
Steve has written a “Sample Printer” Nyquist plug-in but it cannot be run in a Chain and is not suitable for long files:
https://forum.audacityteam.org/t/sample-printer/14790/1 .
Gale
Flac files cannot exceed 0 dB.
WAV files can only exceed 0 dB if they use float format, but “standard” WAV files are usually 16 (or 24) integer format and cannot exceed 0 dB.
This does not mean that they may not be clipped - “clipping” occurs if the signal tries to exceed 0 dB, but for integer formats the signal cannot exceed 0 dB, so the signal is “clipped” at 0 dB.
The free audio player (for Windows) Foobar2000 is able to scan files and calculate the ReplayGain level. If the ReplayGain level shows a large negative number then the file may be clipped and may warrant closer investigation. It will be almost impossible to detect automatically if modern dance music is clipped because it is likely to be so heavily “maximised” for volume that it is intentionally “almost” clipped.
To further complicate the matter, a recording may be clipped below 0 dB, which would be difficult to detect.
To complicate the matter even further, if a small amount of clipping occurs only on the highest peaks, it may not sound clipped, in which case it is not really a problem.
Clipping is not easy to detect automatically - the best test is the listening test.
Right Steve, but surely these are charges that could also be levelled at the existing clipping detection features of Audacity? Yet I assume you are not calling for these to be removed or a lengthy boiler plate legal warning to be inserted prior to use.
FWIW I feel some of these concerns fall away when you understand the provenance of the files you are working with. What I primarily want to use this feature on is a large quantity of vinyl rips I made a long time ago that I know weren’t clipped originally.
However, I then processed them in my favourite program Steinberg Clean and added some EQs, and I now realise this may have led to some clipping. If I could simply isolate the small subset of files in my library where the 0db threshold was reached I would then have a manageable listing task to confirm clipping and either re-rip of re-process with a VST limiter if I still have the original file.
I appreciate the tips for alternative tools I might use for this task. In particular SoX looks interesting and very powerful and is definitely something I will spend some time on. However, even though I suspect I am more comfortable on the command line than perhaps 90% of the Audacity user base, I have to say I like the way the Audacity chains work.
Specifically I think the visual feedback is invaluable. For example I would never have caught the normalise bug in the chain without the visual information provided by the macro style effect, if a block box had merely ground out a ton of files and returned nothing more than a shell prompt.
For that reason I believe you guys in the development team should build on this framework, even if it is duplicating more hacker oriented tools already out there.
More generally I think the bigger question you should be considering is what direction you want to take the program now that 2.0 is out, if you haven’t already done so. FWIW, it seems to me you have the more production related side covered fairly well and my vote would be to build up the toolset with more of a consumer focus.
Yes the same difficulties are there for the existing clipping detection features of Audacity, but a major difference is that those features would normally be used alongside looking and listening to the waveform. If the audio looks or sounds clipped then they can be useful features for indicating exactly where the clipping is occurring.If the audio is obviously clipped but the Find Clipping feature is not detecting it, then you can normalize to 0dB and/or adjust the settings and run it again. With batch processing you are relying entirely on the automatic detection.
It is certainly an excellent and very versatile tool. Because it is a command line program it lends itself very well to batch processing and because the user can write their own batch script it is good for unusual custom tasks that may be so rare as to not be worth developing for a general release program.
It often helps when we know the context of the question.
You can get that information from Foobar2000 by using the ReplayGain scanner.
You’ll not find many of the Audacity developers (programmers) hanging out on this forum - the “crew” here are “support team” rather than developers, however we do pass on information from the forum to others in the development team.
I’d be particularly keen to see support for Nyquist plug-ins to be included in Chains. The task that you describe could easily be done by a Nyquist script.
Feel free to post specific suggestions (as you have been doing) 
Hello Shaky,
I realize this is an old thread but I just bumped into it and thought I would post. Check this thread: http://forum.audacityteam.org/viewtopic.php?f=48&t=69430&start=10 . I had the same query(I think) as you and asked for help here on this forum for help with a bash script to find all clipped tracks. Ragnar was the person who helped me out. Anyway, I use that script all the time and it scans thru all files in the library and prints to screen and log all tracks that fail a given limit that you set in the script. I have tweaked the script a bit but it works perfectly without fail and finds tracks with clipping nicely. It is pretty anal to tell you the truth, it finds tracks with only a single clip. The only thing you have to do is add Replay Gain to your flac files then run the script and it will log all of the tracks with clipping. It doesn’t fail to find clips, you may be surprised at how clipped your library is, I know I sure was. Anyway I am clip free now. If you want I will post the latest version of my script, it really works a treat. Give that thread a read and see if it’s what you need.
Cheers,
Singtoh