Detecting whether a 24-bit file has been upconverted from 16-bit? Options

[Arnold B. Kruege...]

I downloaded a FLAC album from online web store and it appears that the files I've downloaded are 24-bit. it's not a hd web store like hdtracks, it's generally a CD 16-bit 44.1kHz store with either FLAC or MP3 to choose from in its offerings.

I'm wondering whether the 24-bit files are real and were supplied as 24-bit from the label and they just didn't label it correctly on the download page, or whether there was an encoding error or just somehow it made its way from 16-bit files to 24-bit FLACs.

Is there a way I can definitively tell or analyze it (looking at spectral maybe) to see if it's been upconverted? Are there certain algorithms and 'good jobs' that can be done to make its 16->24 upconversion undetectable?

Many of the actual upconversions are going to be pretty hard to determine by simple means. For example it is pretty well known that about half of all so-called HD tracks started out as analog tapes or non-CD digital recordings that either came from or passed through the analog domain during the transcription process.

Catching only the clerical errors and obvious transcription errors is only a partial solution.

[Sparktank]

CODE

flac -ac foo.flac | findstr wasted_bits (for windows)

fbits:

CODE

#!/bin/bash

me="${0##*/}"

if [ -w "$TMPDIR" ]; then
tdir="$TMPDIR"
elif [ -w '/tmp' ]; then
tdir='/tmp'
elif [ -w "$HOME" ]; then
tdir="$HOME"
elif [ -w "$PWD" ]; then
tdir="$PWD"
else
echo "$me: error: can't find a writable directory for creating the temporary file" 1>&2 ; exit 1
fi

tf="$( TMPDIR="$tdir" mktemp "${tdir}/${me}.XXXX" 2>/dev/null )"
if [ -z "$tf" ]; then
echo "$me: error: can't create temporary file" 1>&2 ; exit 1
fi

checkbits ()
{
local bps abps tbps=0 n=0
bps="$( metaflac --show-bps "$1" )"
flac -ac "$1" 2>/dev/null | fgrep 'wasted_bits' | cut -d '=' -f 3 | cut -f 1 > "$tf"
while read wb; do
tbps=$(( tbps + ( bps - wb ) ))
((n++))
done < "$tf"
abps=$(( ( ( tbps * 10 / n) + 5 ) / 10 )) # (* 10 + 5) / 10 for proper rounding
printf "%2u/%2u bits\t%s\n" "$abps" "$bps" "$1"
}

for f in "$@"; do
case "$f" in
*.flac) checkbits "$f" ;;
*) continue ;;
esac
done

rm -f "$tf"

Usage:

CODE

fbits *.flac

Can anyone convert that Unix BASH script for Windows BATCH script?
I don't want to install anything more, I've got so much installed already.

Windows 7 (x64) and Windows XP (x86) user.

Using what nu774 provided gives me over 4,000 lines of text.
It would be more convenient to have summarized results in a printed text file.

Thanks for any help.

PS: I've ready looked at a few threads where people were trying, miserably, to install software to use BASH scripts on a Windows environment.
Those threads didn't seem entirely successful and were incomplete in instructions.

[skamp]

Maybe Greynol can help?

[Case]

Here's a quick Windows .cmd script trying to do the same thing:  fbits.zip ( 601bytes ) Number of downloads: 27

[Sparktank]

Here's a quick Windows .cmd script trying to do the same thing:  fbits.zip ( 601bytes ) Number of downloads: 27

Thank you! But it's hard to figure out why it's not working.
I've replaced the only isntance of the program call with the filepath of the actual program.

It just opens and then closes right away.

[Case]

It's meant to be used from command prompt when flac.exe and metaflac.exe are in search path. You can add "pause" command as the last line and then you can drag and drop .flac files over it. For drag and drop use it's enough to have flac.exe and metaflac.exe in the same dir as the .cmd file.

This post has been edited by Case: Apr 13 2013, 10:11

[mjb2006]

Thanks for the .cmd version.

I suggest modifying it to use flac -acs rather than flac -ac, so you don't get the copyright/warranty/license header after every file it processes. (Maybe this varies by flac build?)

[Arnold B. Kruege...]

I downloaded a FLAC album from online web store and it appears that the files I've downloaded are 24-bit. it's not a hd web store like hdtracks, it's generally a CD 16-bit 44.1kHz store with either FLAC or MP3 to choose from in its offerings.

I'm wondering whether the 24-bit files are real and were supplied as 24-bit from the label and they just didn't label it correctly on the download page, or whether there was an encoding error or just somehow it made its way from 16-bit files to 24-bit FLACs.

Is there a way I can definitively tell or analyze it (looking at spectral maybe) to see if it's been upconverted? Are there certain algorithms and 'good jobs' that can be done to make its 16->24 upconversion undetectable?

It all depends on how the file was upconverted.

If a schlock job was done, and the file was converted from 16 to 24 by simply padding with zeroes, then that would be detectable by obvious means.

If a good job was done with a properly dithered conversion, then I don't know of a reliable numerical test for that.

I'd like to see people explain why their code fragments should be reliable, and then demonstrate that their code fragments are reliable detectors of upsampling if the file was upsampled correctly.

[greynol]

I don't see the point in adding dither when increasing the bit-depth.

[skamp]

I'd like to see people explain why their code fragments should be reliable, and then demonstrate that their code fragments are reliable detectors of upsampling if the file was upsampled correctly.

Is that directed at me? I make no such claim.

[Arnold B. Kruege...]

I don't see the point in adding dither when increasing the bit-depth.

Cover up. Keep it from being easy to detect your trickery.

[BearcatSandor]

Anyone know how to adjust Skamp's script to work with wavpack files (hybrid in my case)? Wvunpack -ss doesn't seem to supply the needed information

Thanks

[Kees de Visser]

I don't see the point in adding dither when increasing the bit-depth.

Cover up. Keep it from being easy to detect your trickery.

I suppose you mean: make bits 17-24 active because them being static zeros would reveal that they are not part of the original signal.
To make sure all 8 bits are effected, a tiny bit of DSP (e.g. a level change of -0.01dB) would be more effective IME since dither might not toggle all 8 bits.

[MikeFord]

How would this technique rate a file consisting of a single loud piano note every few seconds with some softly spoken voice?

How do different masterings come out, something lower level vs the loud nonoise version?