Detecting audio transcoding with ffmpeg

import side-effects

It would be convenient to package up that top-level logic within a def function, and only call that function within the usual if name == "main": guard. That way we could write a few unit test modules which import without undesired print() side effects.

Also, better to from pathlib import Path than to use the clunky old os.path API.

Returning a 4-tuple works fine, but consider making it a namedtuple or @dataclass.

magic numbers

There are a few parameters for which the values seem "reasonable", like band size and noise floor, but for which it's hard to tell if another value would lead to better {precision, recall} performance.

    for pct in [0.25, 0.4, 0.6, 0.75]:

Those percentages don't seem especially well motivated. Maybe they're arbitrary, and there's just a few in order to conserve CPU cycles? Maybe they're following the curve of some distribution?

bad input

        maxcutoffhz = None

I feel it's reasonable to raise in that case, as we sort of have "nothing to talk about" and all bets are off. Caller will notice the exception. In contrast, returning a float | None type makes it more likely the caller will do something silly like calling round(None, 2), and since it happens long after the call it will be less clear where the bug came from.

reproducibility

It would be helpful to share a link to the GitHub repo where you're developing this, even if it does not yet produce the hoped for results.

ground truth

We're writing a classifier, here. To evaluate its performance (accuracy and recall), we will want to have labeled instances to feed to the classifier.

Fortunately this is straightforward for this particular classification task. Do mkdir in/64kbps out/128kbps out/256kbps. Put a few low bitrate MP3s into that input folder, and use ffmpeg -i to verify they're all recorded at 64 kbps. Then use ffmpeg or some other tool to upsample and create "fake high quality" recordings in those output folders. Great! Now we have a bunch files of known provenance. We can use them to assess our classifier.

Feed each of the files in the output folders to the classifier, and verify that it correctly detects the upsampling. Repeat for the input folder, and verify that it correctly says there was no upsampling. If you do this for many files, it would be convenient to summarize the results in a confusion matrix:
from sklearn.metrics import confusionmatrix

Thanks for the response! :)

This is a demo script. Once I'm happy with it, I'll rewrite it in a different language, so the Python-specific feedback isn't really relevant. I should have mentioned this in the post.

Did you spot any issues/improvements with the algorithm itself?

The algorithm doesn't appear to be based on any published work, given that you didn't cite any book, URL, or other references. So we can't compare the source to the citation and verify it faithfully followed some "known good" technique.

For me to assess the algorithm's fitness for the stated purpose, someone would need to do the "measure against ground truth" work that I outlined. Then we could drill down on file segments where the measured precision was poor, and diagnose what went wrong. I imagine there's more than one popular tool for upsampling, and that different tools and filters introduce different kinds of artifacts, which might lead to more than one failure mode for the classifier.