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?
happy to upload a sample if it helps.
thanks
vince
Try something like the following to see if wasted bits is equal to or greater than 8 for each FLAC sub-frames.
flac -ac foo.flac | findstr wasted_bits (for windows)
flac -ac foo.flac | grep wasted_bits (for Unix like OS)
Are there certain algorithms and 'good jobs' that can be done to make its 16->24 upconversion undetectable?
You could do it with a compander, and some all-pass filtering for good measure, but you'd probably not like the results: the quiet bits would likely be too quiet.
>Are there certain algorithms and 'good jobs' that can be done to make its 16->24 upconversion undetectable?
I think if they converted frequencies up and down it would be difficult to spot as there would not be 00000's in the lower byte.
Try something like the following to see if wasted bits is equal to or greater than 8 for each FLAC sub-frames.
Thanks! I used your idea to make a BASH script (http://pastebin.com/v6qgZ7A0) that prints out the average number of effective bits of FLAC files.
fbits:
#!/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:
fbits *.flac
Output with a lossyFLAC album (Daft Punk - Homework):
12/16 bits 01. Daftendirekt.lossy.flac
11/16 bits 02. WDPK 83.7 FM.lossy.flac
11/16 bits 03. Revolution 909.lossy.flac
10/16 bits 04. Da Funk.lossy.flac
11/16 bits 05. Phœnix.lossy.flac
10/16 bits 06. Fresh.lossy.flac
11/16 bits 07. Around the World.lossy.flac
10/16 bits 08. Rollin' & Scratchin'.lossy.flac
11/16 bits 09. Teachers.lossy.flac
10/16 bits 10. High Fidelity.lossy.flac
10/16 bits 11. Rock'n Roll.lossy.flac
12/16 bits 12. Oh Yeah.lossy.flac
11/16 bits 13. Burnin'.lossy.flac
10/16 bits 14. Indo Silver Club.lossy.flac
10/16 bits 15. Alive.lossy.flac
11/16 bits 16. Funk Ad.lossy.flac
Output with a "true" 24 bit album (The Beatles - Love):
23/24 bits 01. Because.flac
22/24 bits 02. Get Back.flac
22/24 bits 03. Glass Onion.flac
23/24 bits 04. Eleanor Rigby ∕ Julia (transition).flac
22/24 bits 05. I Am the Walrus.flac
21/24 bits 06. I Want to Hold Your Hand.flac
22/24 bits 07. Drive My Car ∕ The World ∕ What You're Doing.flac
23/24 bits 08. Gnik Nus.flac
22/24 bits 09. Something ∕ Blue Jay Way (transition).flac
22/24 bits 10. Being for the Benefit of Mr. Kite ∕ I Want You (She's So Heavy) ∕ Helter Skelter.flac
21/24 bits 11. Help.flac
22/24 bits 12. Blackbird ∕ Yesterday.flac
22/24 bits 13. Strawberry Fields Forever.flac
22/24 bits 14. Within You Without You ∕ Tomorrow Never Knows.flac
22/24 bits 15. Lucy in the Sky With Diamonds.flac
22/24 bits 16. Octopus's Garden.flac
22/24 bits 17. Lady Madonna.flac
22/24 bits 18. Here Comes the Sun ∕ The Inner Light (transition).flac
22/24 bits 19. Come Together ∕ Dear Prudence ∕ Cry Baby Cry (transition).flac
22/24 bits 20. Revolution.flac
22/24 bits 21. Back in the U.S.S.R..flac
23/24 bits 22. While My Guitar Gently Weeps.flac
22/24 bits 23. A Day in the Life.flac
22/24 bits 24. Hey Jude.flac
22/24 bits 25. Sgt. Pepper's Lonely Hearts Club Band (reprise).flac
22/24 bits 26. All You Need Is Love.flac
Output with a 16 bit album, upsampled to 24 bits (Daft Punk - Homework):
16/24 bits 01. Daftendirekt.flac
16/24 bits 02. WDPK 83.7 FM.flac
16/24 bits 03. Revolution 909.flac
16/24 bits 04. Da Funk.flac
16/24 bits 05. Phœnix.flac
16/24 bits 06. Fresh.flac
16/24 bits 07. Around the World.flac
16/24 bits 08. Rollin' & Scratchin'.flac
16/24 bits 09. Teachers.flac
16/24 bits 10. High Fidelity.flac
16/24 bits 11. Rock'n Roll.flac
16/24 bits 12. Oh Yeah.flac
16/24 bits 13. Burnin'.flac
16/24 bits 14. Indo Silver Club.flac
16/24 bits 15. Alive.flac
16/24 bits 16. Funk Ad.flac
BTW, I think just a slight gain scaling from the original would be enough to fill full 24bits.
For example, you can choose scale factor 0.9, which doesn't have finite binary representation.
You can add noise or simply use Audacity which can change all of the data with a mere save command without having to perform any editing, provided you didn't change the program's silly and annoying default behavior.
Just about anything you do to randomize the least significant 8 bits will likely be inaudible if the rest of the bits are being used and the playback volume is held at a sane level.
Also, spectral views are intended to view frequencies. They aren't going to be very useful in detecting minute changes in amplitude.
There's no way of knowing for sure. Unlike low bitrate mp3 encoding, converting to 16-bits leaves no tell-tale signature.
Once "up-converted" to 24-bits, it's trivial to fill the bottom 8 bits with noise (any operation, even a tiny gain-change, will fill them with some non-zero values anyway). Noise-shaped dither at the 16-bit level could be a tell-tale, but it might not have been used, and if it was, you can use a filter to drop the level to something benign looking. A similar rising noise spectrum (though only above 20k, and at a lower level) is also found on DSD-sourced recordings - so you don't need to be that careful - just dropping it to DSD-like levels will do the trick.
A recording with analogue silence won't give anything away, but a recording with 16-bit dithered digital silence could alert some people. In this case, it's easy to replace it with 24-bit digital fades and silence.
So, as I said, there's no way to know.
If you had both the 24-bit and 16-bit versions, you could show that the 16-bit version was probably generated from the 24-bit version (if it was), rather than the other way around - but you couldn't prove that the 24-bit version itself wasn't generated from a previous 16-bit version.
So, if version A=24-bits and version B=16-bits, you could show that B was created from A, rather than A being created from B. But you cannot show that A was not created from U, a 16-bit version that you don't have access to. That possibility always exists, and you cannot disprove it.
(I am assuming a real recording in a normal recording studio with real microphones, which will almost always result in a noise floor that's far above the 16-bit dithered noise floor. If you had an entirely synthetic recording, it could have an arbitrarily low measurable noise floor, far below 16-bit dither, and here you could very easily prove whether it was native 24-bits, or upconverted from 16-bits).
Cheers,
David.
Thanks guys (and yeah thanks greynol for pointing that out about the spectral view), I now have confirmation from the webstore that it was an encoding error when ripping from the physical CD disc to upload on the store.
I'd like to see if those ideas above show anything.
So Now that I know more of how the 24-bit files were created: well obviously it was somewhere at the FLAC encoder level? Looks like they accidentally had 24-bit (flac) output selected in whatever ripping program they used, and that's how it happened. probably first extracted as 16-bit wav, but then converted from that into 24-bit flac, you think? with that in mind, any more clarity of how one could detect a flac.exe-produced 24-bit blow-up job?
Also, get this: their response to me pointing out the error, was such that they weren't actually to take any action unless I requested them to. they merely said 'This does not detract from the files but means that they are slightly larger than they need to be.' They actually are twice the size they need to be.
They seemed content with me wasting hard drive space for absolutely no reason, just because they, a professional music downloads web store, made a mistake when ripping the files.
Lazy.
NOW, after telling them I either want a refund or re-ripped files from the disc, within 5 minutes they have come back and said they have new (fixed) 16-bit files for you on the store. they obviously didn't re-rip the files from the disc, they clearly just downconverted the 24-bit files to 16-bit, right??? and unless that's done with a really good dithering algorithm, that could be inferior to an original straight rip from the 16-bit, right?
what's the bet they used some dodgy program (like, I dunno, is dbpoweramp a good example of dodgy?) to downconvert it again? Should I continue to not be satisfied and point this out to them, and demand a proper true lossless re-rip with no mucking around, and also is there a way to detect whether something's been (with damage), downconverted from 24-bit to 16-bit (I guess this is impossible without comparing it to an original perfect CD rip from the original unprocessed 16-bit.....?)?
ah - started writing this before finishing reading 2Bdecided's reply.....well with this in mind (16->24->16), is there any way I can at least prove the 24->back to->16 bit, bit?
Don't blame flac.exe. It will not take 16-bit input and produce a 24-bit encode. The processing occurred before the compression.
dBpoweramp is not a dodgy program. While foobar2000 can be configured to produce a 24-bit flac from a 16-bit wave, it isn't a dodgy program either.
Hopefully they didn't use dither when converting the 24-bit files into a 16-bit files or that will ruin any possible chance that you arrive back at the original 16-bit data. With respect to the conversion from 16-bit to 24-bit, dither can only compromise quality. Dither is used to de-correlate error when processing data. When reducing bit depth is the only processing, dither is really only useful when going from a higher depth to a lower one, and only when the higher depth actually has meaningful data in the bits that will be discarded.
They actually are twice the size they need to be.
Are you sure? I just tried upconverting a 16 bit album in FLAC to 24 bit, and the resulting FLACs are almost the same size at the originals.
As a sidenote, I scanned my entire FLAC collection with my script, and I found an oddity: the album "Smash" by The Offspring only has 15 effective bits (out of 16, it's a CD rip). I wonder why that is.
6dB of gain was applied to the master with no further processing?
Don't blame flac.exe. It will not take 16-bit input and produce a 24-bit encode. The processing occurred before the compression.
Ah yeah that makes total sense. sorry about not thinking much. it's been a long time since I have been active in audio softwares and the like, really.
dBpoweramp is not a dodgy program. While foobar2000 can be configured to produce a 24-bit flac from a 16-bit wave, it isn't a dodgy program either.
well, I just mean more anything that's not sox/weiss etc. grade dithering.
A originally assumed dbpoweramp just was dodgy but then thought, well, how can i assume that. of course - i am nowhere near knowledgable, nor aware of any improvements made to other systems/softwares.
i'll be honest in acknowldging my purist tendancies here...
Hopefully they didn't use dither when converting the 24-bit files into a 16-bit files or that will ruin any possible chance that you arrive back at the original 16-bit data. With respect to the conversion from 16-bit to 24-bit, dither can only compromise quality.
Well I wouldn't bet they know what they're doing. They'd be I'd say most likely using some one-click solution and wouldn't have even heard of the word dither before. (I'm at least one step higher than that ;P.)
So should I demand the web store to re-rip from the CD (saying that this multi-step processing has rendered the file anything
but lossless), or is it likely these 16->24->16 files are not too damaged?
This is what i want to try and find out through a bit of audio analysis, or make a judgement on.
You would really have to go out of your way to do 16 -> 24 -> 16 for it to result in audible degradation.
They actually are twice the size they need to be.
Are you sure? I just tried upconverting a 16 bit album in FLAC to 24 bit, and the resulting FLACs are almost the same size at the originals.
When I convert my originally-provided and bloated 24-bit files to 16-bit flac with foobar (and yes I've checked compression levels too, to make them equivalent, as much as I can guess), it's more than a ratio of 2:1. so yes it's definitely twice too much pointless stuff they were making me download and store on my hard drives.
You would really have to go out of your way to do 16 -> 24 -> 16 for it to result in audible degradation.
Ok I guess I'll leave it be then. Thanks.
it's more than a ratio of 2:1
Then they probably did something more than a straightforward 16 to 24 bit conversion (shifting values by one byte).
Interesting discussion. I hope the market does not attempt to sell consumers 24/96 downloads of "high quality" that were converted from CD sources. Yuck. Reminds me of another discussion of shrink-wrapped CD's with track(s) from lossy sources.
As a sidenote, I scanned my entire FLAC collection with my script, and I found an oddity: the album "Smash" by The Offspring only has 15 effective bits (out of 16, it's a CD rip). I wonder why that is.
6dB of gain was applied to the master with no further processing?
Not to hijack the discussion (and not wanting to start a new thread) but my pressing has no such wasted bits in case you wanted to investigate further.*
*Note: The album gain of my backup image reported a RG value of -7.82. Other than that, the spine area of the back label of my pressing has the number 86432-2. Good luck!
I used your idea to make a BASH script (http://pastebin.com/v6qgZ7A0) that prints out the average number of effective bits of FLAC files.
Many thanks! Ran it on my collection of 20,000 tracks, and only found 6 albums showing significant "unused" bits. One, a pure spoken voice one (language training record) had "effective" bits between 13 and 15 depending on the track, 2 CD's (Smoke & Strong Whiskey by Christy Moore and In My Memory by Dj Tiësto) had consistent 15 bits out of 16, and 2 supposedly 24 bit downloads (A Retrospective by The Unthanks and the LSO Haitink Beethoven Symphony no. 9, both from B&W Society of Sound) had consistent 16 effective bits.
The one strange one was Portico Quartet from B&W Society of Sound:
22/24 bits Portico Quartet/Portico Quartet/10 Trace.flac
23/24 bits Portico Quartet/Portico Quartet/01 Window Seat.flac
16/24 bits Portico Quartet/Portico Quartet/02 Ruins.flac
16/24 bits Portico Quartet/Portico Quartet/03 Spinner.flac
23/24 bits Portico Quartet/Portico Quartet/06 Laker Boo.flac
19/24 bits Portico Quartet/Portico Quartet/05 Export to Hot Climes.flac
16/24 bits Portico Quartet/Portico Quartet/09 City of Glass.flac
20/24 bits Portico Quartet/Portico Quartet/08 4096 Colours.flac
22/24 bits Portico Quartet/Portico Quartet/07 Steepless.flac
An even smarter analysis can figure out which 24-bit (or even 16-bit) values are used, and how often. If there are some values which are unused (e.g. 0 is, 1,2,3,4,5,6 aren't, 7 is, 8,9,10,11,12,13 aren't, etc etc), you have a clear case of undithered conversion and scaling. If values (other than zero) are used disproportionately to those around them, you probably have some strange distortion or scaling. If values at or near full scale are over-used compared with those around them, you probably have clipping.
This technique still won't catch 16>24-bit conversions which added noise in the 8 LSBs, and will often miss problems if the occur before a final stage of (especially noise-shaped) dither. But it's surprising what it does catch.
It's hard to automate the detection of something wrong via this analysis - you mostly just have to eyeball the distribution. For 24-bit audio, it's only meaningful for long pieces of music, given the 16M different possible sample values. With 16-bit audio, you can get meaningful results with more than a minute or so of music.
Cheers,
David.
it's more than a ratio of 2:1
That's using FLAC. What's the bitrate of your 16 bit files? If < 700 ...
I hope the market does not attempt to sell consumers 24/96 downloads of "high quality" that were converted from CD sources. Yuck.
Well ... does it really make a difference? Had the CD standard been 48 kHz, one could maybe easier have exposed a few 24/96's as CD-sourced, and gotten the hi-rez hysteria the bad press it deserves.
Let's not forget that a file that was up-converted from CD will have an integral number of frames, i.e. an exact multiple of 1/75 seconds.
Let's not forget that a file that was up-converted from CD will have an integral number of frames, i.e. an exact multiple of 1/75 seconds.
...if they ripped it properly! ...and didn't skip any silence automatically.
Let's not forget that a file that was up-converted from CD will have an integral number of frames, i.e. an exact multiple of 1/75 seconds.
Good point. Turns out that out of the B&W Society of Sound supposedly 24 bit downloads I looked at, the Portico Quartet one had exact multiples of 588 samples in all of the tracks, and the album by The Unthanks had exact multiples in 6 out of 11 tracks... I guess we know where they came from...
...and it makes sense that if the tracks had been resampled from 44.1 kHz then the low byte of each 24 bit sample would not be zero. Add to this the fact that resampling technically reduces quality, and these files are not as good as the original CD.
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.
flac -ac foo.flac | findstr wasted_bits (for windows)
fbits:
#!/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:
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.
Maybe Greynol can help?
Here's a quick Windows .cmd script trying to do the same thing: [attachment=7493:fbits.zip]
Here's a quick Windows .cmd script trying to do the same thing: [attachment=7493:fbits.zip]
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.
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.
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?)
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.
I don't see the point in adding dither when increasing the bit-depth.
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.
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.
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
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.
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?
Regarding the Windows fbits.cmd, I lost the version I had.
I downloaded the one provided and made some changes to it so it would not only scan the entire directory, but also print logs for each file (the detailed logs) and then pretty much keep the CMD screen clean (reporting only final results) and then printing those displayed results.
I don't know where I put the modified version and I can't remember what I did for the life of me, either.
My cmd skills aren't nearly enough to recreate the existing fbits.cmd and figure out how I did it before.
I remember taking a long time just to try things out and spend hours googling about cmd usage.
I've added FLAC folder (flac/metaflac) to the system_path (not user_path) and I frequently use "open CMD here" on directories via context menu, if that helps.
Whatever's going on in the current cmd doesn't process/summerize whole directory for me and all logs disappear.
Anyone??
I can't even get the original one to work anymore.
I've the flac.exe and metaflac.exe in the same folder as fbits.cmd.
Is there anyone who can start from scratch who doesn't assume everyone who uses it will know automatically what to do?
Not everyone is advanced in batch/command scripting.
It's not clear what you're asking for. You just want the original to work? Still works for me on the command line. I am using the original one provided here.
For one file in somefolder:
fbits "\somefolder\some FLAC file.flac"
For all files starting with "Don" in somefolder
fbits "\somefolder\Don*.flac
This isn't working for you?
Batch files require some special care when dealing with variables that hold special characters like parenthesis or percentage sign. The attached fbits script is modified to handle files and dirs with these characters properly. It also recursively scans all FLAC files in a directory if you pass it a directory. And it pauses at the end automatically so it's directly suitable for drag & drop use. If you prefer to use it from the command prompt remove the "pause" near the end.
[attachment=8138:fbits2.zip]
The script fails to detect whether files have been upconverted from 16 bits to 24 bits if dither is used. Is there any way to circumvent this and modify the script in order to bypass this dither masking files as actual 24 bits files?
Please, this is important. There are some files I really need to know whether they were upconverted.
Is there any way to circumvent this
I don't know anything about the script but
I assume the script isn't the problem... If there is non-zero data in all 24-bits there's no way to know if the 8 least significant bits contain original data or un-original data.
If it's "cleanly" upsampled every sample will have zeros in 8 of the 24-bits. But all it takes is something like a 0.1dB level reduction (or increase) and all of those bits get filled-in. Or you could re-sample to a higher sample rate. You don't have to dither or use any complicated tricks.
I've played-around with some of these tools in the past and they were easy to fool and I recently downloaded
Bitter (https://www.stillwellaudio.com/plugins/bitter/) (which I tried in Audacity). MP3s from ripped CDs show about 30-bits (which is true depending on the MP3 decoder).
I've played-around with some of these tools in the past and they were easy to fool and I recently downloaded Bitter (https://www.stillwellaudio.com/plugins/bitter/) (which I tried in Audacity). MP3s from ripped CDs show about 30-bits (which is true depending on the MP3 decoder).
bitter can't even survive simple dithering, let alone mp3.
https://hydrogenaud.io/index.php?topic=114816.msg992983#msg992983
My software cannot survive lossy compression either, but for basic operations like volume adjustment and dithering, it works.
"Simple" dithering alone without a volume adjustment will fill in bars 22-24, and 17-21 will show less frequency. If the noise shaping is moderate it is even possible to recover the original 16-bit values for something like a compressed SPDIF signal. None of these tools can survive someone intentionally fooling them. Integrated into an audio editor, they are convenient to use to discover accidental problems within the signal chain.
I've played-around with some of these tools in the past and they were easy to fool and I recently downloaded Bitter (https://www.stillwellaudio.com/plugins/bitter/) (which I tried in Audacity). MP3s from ripped CDs show about 30-bits (which is true depending on the MP3 decoder).
bitter can't even survive simple dithering, let alone mp3.
https://hydrogenaud.io/index.php?topic=114816.msg992983#msg992983
My software cannot survive lossy compression either, but for basic operations like volume adjustment and dithering, it works.
...and here are some examples of my software scanning some MQA files:
https://www.audiosciencereview.com/forum/index.php?threads/usb-dac-that-shows-bit-depth-on-display.23349/post-781422
The software doesn't really know what MQA is. For this specific purpose, mansr's mqascan tool should be used.
But then something as simple as playing a 16-bit file and re-digitize the analog output at 24-bit is good enough to hide everything, and I wonder how someone can determine the "true" bit-depth of tracker music or wavetable synthesizer with 4MB of PCM ROM :D
With a rompler, you would talk about the quality of each sample, if it hisses, clicks while looping or otherwise distorts. A sample can be played quietly where its problems don't stand out, but the mix then requires more bits. A wavetable synthesizer has a mixing bit depth. For example the old SYXG-50 drivers were 13 bits and hissed noticeably with tonal sounds like solo piano.
If you took an MP3 file and re-digitized it, a spectrogram would show where the encoder has preserve the original noise floor. If the noise of a given file is always high, then the bit depth can be reduced without any practical loss, without investigating how the noise came to be there.
But how about S-YXG50 vs MU50 vs DB50XG? I don't have any hardware XG synth but I have a Roland SC-D70 and SC-VA.
https://forums.cockos.com/showpost.php?p=1861656&postcount=11
Some people also said the "PCM" ROM of these Roland synthesizers involved lossy compression, but then there is no way to know apart from hacking and dumping the ROM data with detailed analysis.
Don't know if those old XG hardware have decent analog output or not, otherwise there is no way to know if the noise is more related to digital or analog. For a daughterboard it is more related to the noise floor of the soundcard I suppose?
At the end the whole thing is more like ENOB.
Decoding Yamaha's S-YXG50 revealed that the ROM is entirely 8 bit samples.
Decoding Yamaha's S-YXG50 revealed that the ROM is entirely 8 bit samples.
Neat and very cool at the same time.
But how about S-YXG50 vs MU50 vs DB50XG?
(https://40th.com./gfx/w32/xgdsp202.gif)
My first Win32 end-user program. The .gif has a timestamp of
28144 Jun 8 2000 xgdsp202.gif
so 21+ years. Before this I spent my time with another operating system. I can't find any pictures at 40th.com from before this. I had many similar, but more elaborate, programs like this (simple) XG DSP thing. I remember the GUS and its DB. I remember a nice sound card from a company in Montreal that also had a nice XG DB (can't recall the company name -- maybe it was the one with the "db60xg" seen in the gif). There are more. I can't remember them (the '90s, after all).
Decoding Yamaha's S-YXG50 revealed that the ROM is entirely 8 bit samples.
My first Win32 end-user program. The .gif has a timestamp of
28144 Jun 8 2000 xgdsp202.gif
so 21+ years. Before this I spent my time with another operating system. I can't find any pictures at 40th.com from before this. I had many similar, but more elaborate, programs like this (simple) XG DSP thing. I remember the GUS and its DB. I remember a nice sound card from a company in Montreal that also had a nice XG DB (can't recall the company name -- maybe it was the one with the "db60xg" seen in the gif). There are more. I can't remember them (the '90s, after all).
Thanks. I only tried SW1000XG in a music shop, and never owned any real XG hardware, not even a YMF724 soundcard.
Thanks. I only tried SW1000XG in a music shop, and never owned any real XG hardware, not even a YMF724 soundcard.
I own a Yamaha PSR-295 Keyboard! It's XG-Lite. Otherwise all I encountered with XG has been Windows 98 Second Edition software synthesizers of theirs as well as 2 VSTIs.
Another thing is that a single "note" is not a practical representation of the bit-depth of a sample. It is just a preset. A preset can be a combination of more than one sample playing at the same time and each of them can have different envelopes, gain, root key/tuning/pitch shifting and other things, even with all effects like reverb and chorus turned off. With pitch shifting the aliasing also affects effective bit-depth so you even have different effective bit-depth when playing different keys, some patches may include LFO which constantly change the pitch and amplitude of a short period of samples as well.
While I don't disagree the approach of using relative noise floor to approximate effective bit-depth, the same approach can also be used in analog recording like tape and vinyl, regardless of the preceding steps involved digital processing or not (e.g. digital delay lines)
Some examples attached, and a GM file as specified by the author, so should be no compatibility issues.
http://www.vgmusic.com/music/console/nintendo/snes/DKCMine-GM.mid
https://www.un4seen.com/forum/?topic=13919.msg96992#msg96992
"bassmidi 8pt" is the improved version after Ian applied the fix about what I complained. I don't have the old 8pt executable to generate the old version anymore. I also attached another file with linear interpolation. Currently, BASSMIDI is able to perform 16pt interpolation.
Another set is SC-VA vs SC-D70. For those who wonder why there is a low pass in the SC-D70 version, the hardware synth engine operates at 32kHz, and the unit itself supports digital loopback recording, but only at 44.1k and 48k. The unit has a CS8420 SRC chip to do the resampling. "sc-va 48" is directly rendered by setting the VSTi's sample rate to 48k, "sc-va sox" is rendered at 32k and resampled by SoX to 48k with default settings.
In the SC-D70 recording, the rather high noise floor beyond the filter cutoff region is originated from the digital hardware itself, and it will fade to zero when the music ended, and therefore not analog noise. Also, the noise is not related to how many voices are being played simultaneously, or how loud the individual notes are. Even when there is only one note playing, it still has this amount of noise. It does support 24-bit loopback recording, but there is no improvement to the noise, and the attached file is indeed recorded at 24-bit, normalized, and converted to 16-bit flac.
And yes, I also have S-YXG50 VSTi installed so I know how this file sounds like, but I don't know if Yamaha's (AWM2?) synthesis is completely sample-based or not by merely Googling.
I've played-around with some of these tools in the past and they were easy to fool and I recently downloaded Bitter (https://www.stillwellaudio.com/plugins/bitter/) (which I tried in Audacity). MP3s from ripped CDs show about 30-bits (which is true depending on the MP3 decoder).
bitter can't even survive simple dithering, let alone mp3.
https://hydrogenaud.io/index.php?topic=114816.msg992983#msg992983
My software cannot survive lossy compression either, but for basic operations like volume adjustment and dithering, it works.
I used your BitSort on some files I suspect were upconverted and got this
00:03:24.2266666 = 18012792 samples / 2-ch @ 44100Hz
24-bit fixed point
Bit Count Percent
0 216 0,001199148
1 345 0,001915306
2 580 0,003219934
3 1182 0,006562003
4 2342 0,01300187
5 4654 0,02583719
6 8755 0,04860435
7 15113 0,08390149
8 25147 0,1396063
9 40673 0,2258006
10 62006 0,3442332
11 93798 0,52073
12 139010 0,7717294
13 203963 1,132323
14 327332 1,81722
15 553051 3,070323
16 936168 5,19724
17 1547302 8,590018
18 2421430 13,44284
19 3632266 20,16492
20 4271726 23,71496
21 2934699 16,2923
22 752942 4,18004
23 38092 0,2114719
BitSort end
It's not showing any empty bits but what does it mean when there are bits that have more than 1% of total samples?
The distribution of samples are fine, no "hint" of simple upconversion within what the software is able to detect.
The index of bits is an abstraction of audio level, the top (0) denotes silence, the bottom (23) denotes samples located at the highest 6.0206dB, and every lower index denotes the subsequent 6.0206dB.
If you look at the examples I included in the readme file, you can see that in the electronic music album, there are more samples located at the higher bits and they are packed more tightly within a fewer number of bits. On the other hands, the classical album has fewer samples located at the highest bits, and the values spanned more sparsely among more bits. Which means the classical album has a higher requirement of bit-depth than the electronic album.
Your file is somewhere between my two examples, which means the bit-depth requirement is not particularly high.
Updated. BTW, the first example in the ReadMe file is from the "raw DXD" file in this website:
http://www.2l.no/hires/DXD-DSD/index.html
BitSort 1.0.0.1 and oldsCool 1.0.0.1
Cosmetic text formatting fix.
BitSort 1.0.0.1
Faster reading speed, at the expense of not updating progress in console.
Improved error message handling
oldsCool 1.0.0.1
Improved 16.8 float detection reliability.
Download link:
https://1drv.ms/u/s!AvzB71jO7t0-gYwlvR98sw61gS10eg?e=ZpPRgO
SHA256:
5ed97b2cda29483fbf6df5467d97695566eccdd7841fdf6bb2fc30cda07b94b9
As a sidenote, I scanned my entire FLAC collection with my script, and I found an oddity: the album "Smash" by The Offspring only has 15 effective bits (out of 16, it's a CD rip). I wonder why that is.
Not to hijack the discussion (and not wanting to start a new thread) but my pressing has no such wasted bits in case you wanted to investigate further.*
*Note: The album gain of my backup image reported a RG value of -7.82. Other than that, the spine area of the back label of my pressing has the number 86432-2. Good luck!
My copy also seems to have only 15/16 bits. The barcode is 0 4577-86432-2 6, disc ID c20af40e
If the 24 bit file is created from a 16 bit file that has been scaled up and then dithered, then that would be revealed by a statistical analysis to show which numerical values of the samples in the 24 bit file are the most prevalent, because in the case of a scaled up 16 bit file the prevalence of the values in the 24 bit file will be centred on and around the sample values of a scaled up 16 bit file.
TOCID M8xNk7MH32hpf0qL.JypIqlNmHE- and G8N_4thJWyVAqonbYxXVTha8Ej4- are 15 bits.
TOCID kHuYSY4hBILe5qdayvGFXrgTSCg- is 16 bits.
The background noise level of both on a spectrogram is about the same. Only few quiet moments such as the end of Genocide and the hidden track show some differences in undithered fades. For aggressive, compressed rock music 15 bits is enough.
With 8 LSBs added, dither will not fill all of them, so bits 17-20 will switch less often. But one added bit couldn't be detected this way.
On a byte frequency histogram 15 bits show up with regular spikes in every other position. Two unused bits (14-bit) would have spikes every 4 positions, and so on. An undithered volume adjustment, such as normalization in a CD ripper, will show irregular gaps if a quiet section is analyzed.
Updated. BTW, the first example in the ReadMe file is from the "raw DXD" file in this website:
http://www.2l.no/hires/DXD-DSD/index.html
BitSort 1.0.0.1 and oldsCool 1.0.0.1
Cosmetic text formatting fix.
BitSort 1.0.0.1
Faster reading speed, at the expense of not updating progress in console.
Improved error message handling
oldsCool 1.0.0.1
Improved 16.8 float detection reliability.
Download link:
https://1drv.ms/u/s!AvzB71jO7t0-gYwlvR98sw61gS10eg?e=ZpPRgO
SHA256:
5ed97b2cda29483fbf6df5467d97695566eccdd7841fdf6bb2fc30cda07b94b9
Any new download link for the latest bitsort? Just occurred to me check this thread again and see if there were any new posts. The download link you provided no longer works. I was too late.
Posted here:
https://hydrogenaud.io/index.php/topic,114816.msg1010860.html#msg1010860
Thank you