[Flac-dev] Idea to possibly improve flac?

[Declan Kelly]

On Fri, Jan 07, 2011 at 02:22:51PM -0800, brianw at sounds.wa.com wrote:
> 
> First of all, I am not aware of any official source of FLAC files  
> that provide MP3 sourced data.

Unofficial sources (such as Usenet and that torrent site with the old
fashioned sailing ship as its logo) are much more likely to have FLAC
files that were made from lossy audio.

And I vaguely remember reading about an illegal download site that
stored all audio in MP3 (at less than 320k) and transcoded on the fly
for all other bitrates and formats, including FLAC and 320k MP3. They
did it to save storage space.

> However, you should be aware that many modern producers use software  
> to create their music, and when the software stores sound clips in  
> MP3 format, what you end up with is music that sometimes looks like  
> MP3.

I recently bought the double-CD "Influence" remaster by The Art Of Noise
and some rarer tracks were sourced from MP3 because that was all their
archivist could find. Most of the reissue was direct from analogue tapes
so this wasn't a quick "shovelware" reissue job.

> it just has to do with the software that was used to create the music  
> originally.

A friend of mine recorded his band's last album on DCC in the mid 1990s
and released it on CD. It sounds horrible; the lossy compression of DCC
is even worse than MiniDisc's ATRAC. I'm sure this CD would fail most
FFT quality tests, as literally everyone who heard it (not just people
with "golden ears" or good sound systems) complained about the quality.

> In other words, if you try to shut down the FLAC encoder based on an  
> FFT, you might have a lot of false triggers!

I think it's a bad idea for a lot of reasons: checking the source audio
quality should be a job for another tool. Most FLAC users won't need to
check (most of my FLAC files are ripped from original CDs that I own),
and anyone who was trying to fool listeners (or fellow piracy groups)
would either work out how to bypass the check, or (more likely) use an
older version of FLAC.

And it's not in keeping with the philosophy behind FLAC: one thing that
I regularly say to people who aren't sure about using FLAC is that Josh
designed it with no copy protection support: if it was there, someone
would only crack it, so it is effectively useless. And that's probably
why Apple's ALAC is usually bigger than FLAC for the same uncompressed
audio (and why Apple still don't support FLAC in their products).

Stopping a pirate from encoding FLAC is similar to stopping a pirate
from ripping a copy-protected CD: it's a challenge to be overcome, and
it will probably take "them" less time to work it out than it took "us"
to build it. And "they" only need to work it out once. Which is why all
copy protection and DRM sucks, for everyone.


> Nine Inch Nails who provide FLAC files.

The initial free online release of NIN's The Slip had a problem with the
24-bit version: it wasn't the full 24/96. Turns out it was a genuine
oversight by the mastering lab (who used the 24/96 to master the vinyl),
and the true 24/96 files were reissued less than a week later.
So even with the artist fully behind 24-bit FLAC, and doing almost all
of the work in their own studio, things can still go wrong.

> People are selling hardware devices in droves, and  
> they cannot afford to change their firmware every time some random  
> change happens in the FLAC source.  It's actually way better that  
> FLAC is not changing.

The FLAC source can change without violating compatibility. Faster or
more efficient encoding can still produce compressed data that older
decoders can process.

> Some audio turns out smaller with ALAC, other audio turns out  
> smaller with FLAC.  Overall, the average performance is identical.   

I've been trying Flake (an alternative FLAC encoder; all it does is
encode) recently and while it goes way faster than the reference FLAC
encoder in terms of speed, the first encode I tried with it ended up
larger than with the reference encoder, at all compression levels.
The compression levels in Flake go up to 11, but past 9 or 10 there is
no guarantee of full compatibility for playback.

> Many tools run the  
> command-line flac utility behind the scenes.  Others use the FLAC  
> library directly.

About a month ago I was setting up FLAC support for a friend on a
Windows PC. Almost every GUI front end (based on the latest available
download) that I tried was using an out of date version of the FLAC
binary or library, and had the default compression set to -6 or lower.
There is no excuse for not cranking up the compression level on any
modern computer: surely you want to get the files as small as possible?

> I doubt there would be any professional  
> interest in changing things just for the sake of change or "newness."

The only "new" thing I want in FLAC is a fix for a minor bug in the way
the command line tool treats the end of line. If long filenames push the
"percent complete" past the screen width and you are encoding or testing
a lot of files, you can end up with the longer file names having 20 or
more lines on the screen output, and scrolling the previous files off
the screen. My workaround is to use a longer scrollback in whatever
terminal I'm using, or use GNU Screen to get scrollback on a text
console.

-- 
-Dec.
---