Hi all,
I have a bit of a quandary and would very much appreciate input from the audio experts on here.
The TL:DR version is that I am looking for an accessible way to know if the sound levels in an audio file clip in the waveform, besides just listening to it and giving my best guess.
I am streaming some audio from a line-level source and have been adjusting the volume by ear, mainly by raising it in the program I am using. I really was hoping there was a way to actually know if my audio is clipping, even slightly, before it is so bad that you can hear it. As I raise the volume, the sound appears to be slightly compressed, and that to me suggests that there may be some clipping going on already even if it isn’t appearing as distortion.
While I am streaming this audio, I can download archives of the recordings and could then analyze it in an audio editor.
I know that a sighted person can just look at the waveform and see if there are any clipped peaks, and this is what I want to be able to do. Is there any type of solution (JAWS script, NVDA ad-on, etc.) to make that waveform accessible to screen reader users? I have licenses for a couple versions of Sound Forge and Gold Wave and am open to any other suggestions.
Thanks!
Comments
I didn't know I needed this but I do
Even if I have sold it, I had a zoom h1 xlr for a few weeks and I encountered a similar issue where if a solution to what Michael is asking exists it would have been appreciated a lot.
Clipping
Hi Michael, would it be an option for you to analyze audio files with some command-line tools like ffmpeg or sox? If yes, I have an idea how this might be done.
Before I go into detail, let me ask a question for clarification: Are the clipped peaks already present in the audio file - or does the clipping only happen during playback when the volume is set too high?
What I'm Looking For
Hi Teele,
What I'm looking for is a tool or process to be able to tell if there are clipped peaks present in an audio file regardless of playback volume level.
It's my understanding that sighted people can view the waveform and tell if there is something in a file that goes over 0DB. With all of the various audio programs and scripts available, I figured there has to be something out there that would provide spoken output of this information.
If you know of anything that might do what I am looking for, I would greatly appreciate any info. I have limited experience with Command Prompt and am not opposed to learning something new.
Thanks,
Michael
peak watcher
You cold use the peak watcher in reaper to tell you when an audio goes above a set amount of decibels. Not sure if its what you need but you could give it a go.
Audio Hijack
@Igna Triay - Thank you for this tip! I have Reaper installed on my Windows machine but have not used it much. It's been on my to-do list.
Does anyone know if Audio Hijack on Mac offers an accessible way to monitor peaks like the aforementioned Peak Watcher in Reaper? That's the software I'm using for the streams, so if I can adjust that in real-time that would be even better than having to go the route of analyzing archived recordings.
Digital clipping
The ideas I had earlier may not cover the entire issue of clipping. Anyway, here's the part which it can solve:
In a waveform graph, clipping can be identified where the amplitude (vertical axis) frequently rises to the same maximum but never beyond. The same can be expressed in numbers, and this is where the free command line tool named "sox" (short for Sound Exchange) may help.
To analyze an audio file whether if it has clear-cut clipped peaks, you'd run this command at the command line:
... where myfile.mp3 is the file to be analyzed.
sox will then analyze the audio file and print the results to the command window, similar to the following:
The following bits of information from the output are relevant:
Pk lev dB: This is the peak level for the audio file. The value 0.00 means that the peak is at the maximum. It can also be a negative number if the peak is lower.
Flat factor: This number is (sort of) an indirect measure for the length of continuous clipped portions.
Pk count: This is the total number of occasions where the amplitude is at peak (minimum or maximum) level.
If the flat factor is greater than 0 and peak count is greater than 2, the audio contains some clipped portions. The greater these two numbers, the longer or more frequently does clipping occur.
If the audio contains no clipping of that sort, the flat factor is 0.00 and the peak count is 2.
Note that sox can handle WAV, MP3, OGG, FLAC and various other audio file formats but not MP4 and M4A. To analyze such files you need to convert them to a supported format like WAV first.
Sox is available from https://sourceforge.net/projects/sox/. If you need help with running the the command line tool as such, let me know.
Unfortunately, this method cannot detect all types of clipping. Clipping is less clear-cut if it occurs due to a microphone being overdriven before analog to digital conversion. Right now I'm not sure how to detect this type of clipping - it's not easy to identify from looking at a waveform graph either.
Finding clipped peaks vs preventing clipping in the first place
Hmm, I'm slightly confused now: Monitoring the peak level during playback is a solution to a different problem than the one I tried to solve above.
@Teele
Thanks for the link and info for Sox.
To further explain my particular scenario... I am streaming on Broadcastify using Audio Hijack for Mac. I am confident that the audio from my radios going into my computer is itself not clipping. What I am trying to do is see how much I can boost the volume of my broadcast before it clips. As far as I can tell, my best option is to download a recent archive recording, analyze it, then go back and adjust the volume going to the streams accordingly. Then more trial and error until I get it where it needs to be.
Audio hijack
Maybe. Haven't experimented with that specific bit with audio hijack as of yet but maybe.
Reaper
I’d go with Reaper for this. You can set up ReaComp so it dynamically adjusts levels based on peaks. It’s not a one-size-fits-all solution, but radio audio is usually already pretty well leveled anyway, so most of the time it’s just about catching the upper peaks.
The nice thing is that everything is user‑configurable — attack, release, ratio, etc. — so you can make the transitions super slow and subtle, or quick and aggressive, depending on what you’re after.
Use AUPeakLimiter in Audio Hijack
Hi Michael, thanks for the clarification. My first idea (using sox to get the peak count from an audio file) is not relevant in that case.
You've mentioned Audio Hijack, which has support for AU plugins. MacOS comes with various AU plugins from Apple, including one named "AUPeakLimiter".
In the Audio Hijack session, insert the AUPeakLimiter block between the source and output blocks. Then adjust the volume using the Peak Limiter's Pre-Gain parameter. If the signal gets too loud, the limiter kicks in and limits the output volume, thus preventing clipped peaks in case the source gets louder than expected.
@Michael: Reaper and finding peaks
If you use Reaper, there are a number of tools for dealing with peaks.
I always use the dry render options/actions in Reaper to assess audio files or segments of audio. Using these features will produce an html table in your web browser that gives you many statistics for a section of audio including:
length of audio
peak value
number of places where the the audio clipped
momentary and integrated LUFS values ( perceived loudness - good to know when creating podcasts or audio you want to post on line)
etc.
You can also have the cursor placed at the first point where clipping occurs.
You can find a variety of these Reaper actions by hitting F4 to get into the actions menu and typing in "dry render".
There is also a Peak Watcher tool built into Osara that can be useful for monitoring loudness and clipping real time, but I haven't used that.
If you are really interested in knowing more, you might want to join the Reapers Without Peepers forum on Groups / IO where there are many knowlegeable and friendly people who have more answers.
Hope that helps.
--Pete
@Teele
@Teele: Thank you for the tip about AUPeakLimiter! I had no idea this existed. Regarding Sox and other methods for audio files, this is still helpful as part of what I want to do is analyze the audio that is being archived.
For Audio Hijack specifically, do you happen to know if any of the meeters are accessible with VoiceOver? I found blocks for meeters but they don't appear to be accessible... But then again the Mac is my secondary system and I am not a power user by any stretch of the imagination.
@Peter
@Peter - Thank you for this! I will definitely keep this in mind for Reaper--though I haven't even started learning it yet so have a long way to go first. ;-)
Peak meters
There is a free audio plugin called "Accessible Peak Meter", available from https://www.tbproaudio.de/products/accessiblemeters/.
Clipped peaks are not announced through VoiceOver but by a feature which they call "sonifcation": The plugin adds a sine wave tone to the audio whenever the level exceeds an adjustable limit. Depending on a setting, the sine wave tone is either constant or increases its pitch the further the level is beyond the threshold.
Unfortunately, VoiceOver coverage of audio plugins on MacOS seems only half-baked. When you switch to the generic audio unit interface of the plugin, you get access to several dropdown fields and sliders, but VoiceOver does not read out their labels.
There's a Mac and a Windows version of the Accessible Peak Meter plugin. The plugin can be used with Audio Hijack. After installation, I had to reboot for the plugin to become available.
I wwouldn't say voiceover plug-ins coverage is half baked
I'd say it has more to do with an app's ui, if nothing else. I.e, use the same plug-ins in a daw, i.e, logic, reaper etc and they're likely accessible. I think it has to do with the UI of the app where they're beeing used, at least from the testing i've done.