Audio Fake Detector PRO

[ngs428]

Can you attach the log recorded in the ~Report folder?
Actually, since I don't have 88.2 kHz audio files, I couldn't establish completely reliable thresholds.
Generally, an album can have some tracks that are clean and others that are fake if they contain lossy material, even if they come from CDs.

I DM'd a file.

 

[Alessandro Comito]

I DM'd a file.

Thanks for the Excel/CSV work. However, to actually fix the 88.2 kHz threshold issue, I need to see the raw data analysis for those specific tracks.

The CSV unfortunately strips out the granular data (cutoff, slope, ratio per segment) that I need to recalibrate the logic. Could you please provide the content of the ~Report .log file?

If the log file is too big to upload, please just send me the lines related to the 88.2 kHz tracks. That raw data is exactly what I need to tune the engine properly!

 

[mcochris]

Not a fake detector, but a similar audio quality tool:

https://www.audiosciencereview.com/...en-source-audio-metrics-tool-for-linux.71176/

 

[SlowJim]

Pro tip for anyone just discovering this amazing tool as I have: delete all your replaygain files first. I use foobar2000 to add replaygain to my flac files and it generates a bunch of hidden files, which this tool gets hung up on. I tried Fakin' The Funk in the past but it gave me a ton of false positives.

 

[Alessandro Comito]

Updated 2026-07-19

 

[Alessandro Comito]

Updated v7.7 2026-07-21
Released v8.0 2026-07-24 → Recommended for faster analysis

audiofakedetectorpro/README.md at main · alessandrocomito/audiofakedetectorpro

Detects audio sourced from low-bitrate material (e.g. 128–160 kbps MP3s) that has been transcoded or upscaled to fake high-bitrate or lossless formats. - alessandrocomito/audiofakedetectorpro

github.com

 

[Alessandro Comito]

The analysis takes roughly the same time on a 1 MB file as on a 100 MB (or even larger) file because the program does not analyze the entire file.

Instead of processing the whole track second by second, the tool only takes 4-5 short "snapshots" (called slots) at specific points in the song.

You can see it clearly in this example: slot@98s → slot@176s → slot@294s → slot@372s → end@442s

Only these short segments are analyzed with the Hi-Res spectrogram (even though the track is 7 minutes and 22 seconds long).

This applies both to the length of the track (2 minutes or 2 hours makes very little difference) and to the sample rate in kHz (44.1 kHz, 96 kHz, 192 kHz).

A 192 kHz file is much larger because it contains about 4× more samples per second than a 48 kHz file.

However, since the tool only analyzes a few brief segments instead of the entire data stream, the processing time remains almost identical.

In short:
- It is not decoding and analyzing hundreds of megabytes of audio.
- It is only looking at a few scattered seconds of the track, regardless of resolution (kHz) or total duration.
- So it's not thanks to a super-fast CPU, but to the smart, efficient method the tool uses (slot-based sampling).

Result: nearly constant analysis time, whether the file is small or a huge high-resolution one.

P.S. Version 7.7 was released on 2026-06-22.

EDIT (correction): The claim in my post above that duration makes "very little difference" isn't accurate - I need to walk it back.

The analysis does only sample a handful of short slots (5) instead of decoding the entire file second by second, and total file size genuinely has very little effect on analysis time for that reason - a 1 MB and a 100 MB file, same duration, do take roughly the same time.

But track duration itself does matter, for a different reason than file size: before picking those 5 slots, the tool scans several candidate positions around each one to avoid landing on a silent/breakdown passage, and the number of candidates scales up for longer tracks.
On a typical few-minutes album track this overhead is small and mostly invisible.
On a multi-hour DJ set it adds up to meaningfully more read operations - and if the file sits on slow storage (external HDD/USB rather than an internal SSD), each of those extra reads costs real time, since seeking around inside a large file on a mechanical or slow-bus drive is far more expensive than on fast local storage. I've measured this directly on real multi-hour external-drive files and the difference versus a short album track is not negligible.

The kHz/sample-rate part of the original claim still roughly holds - the tool works from a handful of fixed-length segments, not the whole stream, so 44.1/96/192 kHz files don't scale the same way total file size would.

Apologies for the earlier overstatement.

 

[Alessandro Comito]

Updated 2026-07-25

 

[Alessandro Comito]

Updated 2026-07-29

 

[ngs428]

Updated 2026-07-29

Thanks for the continued updates! Are you able to post the changelog here for the latest revs when you announce it?

 

[Alessandro Comito]

Thanks for the continued updates! Are you able to post the changelog here for the latest revs when you announce it?

Done

 

[Sal1950]

I wonder how often this type of thing goes on?
And from what sources this embezzlement is being seen?
I don't think you'll find much of it being distributed thru normal label channels?

 

[Alessandro Comito]

I wonder how often this type of thing goes on?
And from what sources this embezzlement is being seen?
I don't think you'll find much of it being distributed thru normal label channels?

That's a fair question. I don't have hard statistics on prevalence, and I wouldn't trust any number claimed without solid data behind it.

My own source is SoundCloud, and that alone is reason enough to need this kind of check. Uploads there pass through various encoding pipelines before they reach you, and a lossy source can end up repackaged into a lossless or "hi-res" container along the way without that being disclosed or even something the uploader is aware of. Sample rate, bit depth, and file extension will all report cheerfully as legitimate even when the actual audio content was upsampled from something lossy.

So the tool isn't about verifying some particular distribution channel is "risky" - it's simply that you can't tell a genuine hi-res/lossless file from an upsampled one just by looking at its properties. You have to check whether the real spectral content matches what the format claims, regardless of where the file came from.

 

[Sal1950]

My own source is SoundCloud, and that alone is reason enough to need this kind of check. Uploads there pass through various encoding pipelines before they reach you, and a lossy source can end up repackaged into a lossless or "hi-res" container along the way without that being disclosed or even something the uploader is aware of. Sample rate, bit depth, and file extension will all report cheerfully as legitimate even when the actual audio content was upsampled from something lossy.

OK, thanks for the info. Being honest I'd never even heard of the SoundCloud streaming service before? I do vaguely remember a few scandles back in the earliest days of HDTracks where it was claimed a few of their "high res" products were simply upsampled RedBooks? Long time ago and I can't remember the details any more.

 

[Alessandro Comito]

OK, thanks for the info. Being honest I'd never even heard of the SoundCloud streaming service before? I do vaguely remember a few scandles back in the earliest days of HDTracks where it was claimed a few of their "high res" products were simply upsampled RedBooks? Long time ago and I can't remember the details any more.

SoundCloud, like HearThis, offers not only streaming but also free downloads, provided, of course, that the user has consented to the downloading of the tracks they have uploaded.

 

[Sal1950]

SoundCloud, like HearThis, offers not only streaming but also free downloads, provided, of course, that the user has consented to the downloading of the tracks they have uploaded.

Ah, I get it, a bit like Bandcamp where amateurs attempt to get heard. Kool

 

[Alessandro Comito]

Updated 2026-08-01

 

[Alessandro Comito]

Portable only: updated 2026-08-02

 

[Alessandro Comito]

Updated 2026-08-03
- Added DSD support

Edit: If anyone has trouble accessing GitHub, they can download the README.md file, which includes a link to the latest version hosted on Google Drive.

Audio Fake Detector PRO

App Name: Audio Fake Detector PRO v7.7 Truly Free Alternative Description: Detects fake high-quality audio files by identifying lossy-to-lossless transcodes Compatibility: Windows 10/11 (32/64-bit), PowerShell 5+ License: Freeware, source available for reference/inspection (not for...

gearspace.com

 

[ngs428]

Updated 2026-08-03
- Added DSD support

Edit: If anyone has trouble accessing GitHub, they can download the README.md file, which includes a link to the latest version hosted on Google Drive.

Audio Fake Detector PRO

App Name: Audio Fake Detector PRO v7.7 Truly Free Alternative Description: Detects fake high-quality audio files by identifying lossy-to-lossless transcodes Compatibility: Windows 10/11 (32/64-bit), PowerShell 5+ License: Freeware, source available for reference/inspection (not for...

gearspace.com

DSD support. Thanks!!!