Any automated way to tell of an MP3 track is compressed

[pfarrell]

I can't help you with detecting pre-existing compression, but have one other comment.

Yeah, i've given up on that idea. What I'm going to do is write a small "telltale" file into the directory that tells me it has been processed thru sox/fb2k Its gotta be batch, as of today, I'm up to 352 artists, and 3922 songs.

BTW, I'm using the Apache license on the tools I'm writing, and its all up on github

[bakker_be]

Back to your original question, best way I know to batch-check dynamic range is the foobar "Dynamic Range Meter" plugin: https://wiki.hydrogenaud.io/index.ph..._dynamic_range)

[pfarrell]

I have a script running sox to apply the "compand" process. Its been running for about 24 hours. I have no way to know how far its along. I guess it might be half done.
The script looks like

sox -V2 -v 0.98 --norm -G "/home/.../mp3/.../Angel of the South.mp3" "/home/.../mp6/.../Angel of the South.mp3" compand 0.3,1 6:-70,-60,-20 -4 -90 0.2

sox -V2 -v 0.98 --norm -G "/home/.../mp3/.../Big Sky Country (Nashville version).mp3" "/home/.../mp6/.../Big Sky Country (Nashville version).mp3" compand 0.3,1 6:-70,-60,-20 -4 -90 0.2

sox -V2 -v 0.98 --norm -G "/home/.../mp3/...Big Sky Country.mp3" "/home/.../mp6/.../Big Sky Country.mp3" compand 0.3,1 6:-70,-60,-20 -4 -90 0.2

sox is constantly warning that it has "clipped" a few thousand points in most files.
I tried adjusting the prameter, and added three paramters that were suggested would lower the number

-v 0.98 is supposed to lower all of the volume/gain by 98%

--norm turns on normalization

--G turns on automatic gain respect.

In theory, each of these will stop the warnings, but so far, not really

[cliveb]

sox is constantly warning that it has "clipped" a few thousand points in most files.
I tried adjusting the prameter, and added three paramters that were suggested would lower the number

-v 0.98 is supposed to lower all of the volume/gain by 98%

I've never used the -v option, but the man page says it's a "linear" adjustment. Which suggests to me that -v 0.98 sets the volume to 98%. And of course that's a very small decrease (about 0.17dB) and won't deal with any induced clipping.

Edit: come to think of it, shouldn't a compressor always REDUCE peak levels prior to applying makeup gain? In which case why would it ever create clipping?

[pfarrell]

come to think of it, shouldn't a compressor always REDUCE peak levels prior to applying makeup gain? In which case why would it ever create clipping?

Good question. sox is cool, but hasn't had any updates in a decade. There are many bugs reported, some which I ran into. Some could be trivially and quickly fixed in the HTML source. I guess the authors have moved on.

Yeah, I ran a small selection of files with various -v from .98 down to .90 and had very little impact on the number of WARN messages.
And the --norm and -G are supposed to fix it as well.

The sox script finished after about 24 hours. Maybe a bit more.

[MainSqueeze]

I've never used SoX's "compand" effect myself but, looking at your code examples above, I'd suggest you ignore the -G and -v options and instead increase the compand attenuation itself until SoX no longer reports clipping: you've set it at -4 at the moment; try something like -12 instead to see if that reduces the number of clipped samples.

You may also want to Google "sox compand effect clipping" (including the quotation marks); it brings up a fair number of results, e.g. the first reply in this 1-page thread or the first five posts in this similarly short thread.

Incidentally, last year, when someone on Audio Science Review claimed that SoX was no longer being updated, one of its contributors, Mans Rullgard, who I gather is also among the top contributors to FFmpeg, had this to say: "Is there some bug you're hoping to get fixed, or are you just addicted to updates?" He has a wonderful way with words, and I'm sure he'd be happy to sort you out.