[Flac-dev] Idea to possibly improve flac?

[Declan Kelly]

On Fri, Jan 07, 2011 at 05:11:26PM -0800, brianw at sounds.wa.com wrote:

> Lots of comments throughout this one...

And I'm going to cherry-pick a few replies as it's getting late.

> What I found most interesting was that I had  
> hired a professional studio in Seattle, and the owner actually stuck  
> his head in the room for this one track.  He'd heard a lot of  
> interesting music in the local scene, but nothing that messed up.

My friend's band was some kind of Metal, so you might expect most of
their fans to be nearly deaf, or unable to tell the difference. But most
of them did. All their previous stuff was recorded and mixed (and then
released) on analogue cassette, and sounded way better. DCC was still
pretty new at the time, so he chose to "upgrade" the portastudio to DCC
instead of MiniDisc, because DCC was backwards compatible with cassette.


[NIN 24/96]

> Thanks!  That's interesting to note.  I think that I ended up with  
> the true 24/96 files, but I am curious: How do you tell whether you  
> have the full 24/96 or not?

Extract to WAV, do a hex dump, and look for repeated 0x00 bytes. Someone
on the hydrogenaudio forums did that, reported it on the NIN forums, and
Reznor got the reissued 24/96 FLAC'd and seeded on tracker.nin.com in a
couple of days.

> 16-bit audio samples stored in a 24-bit file format.  Frequency  
> analysis makes it obvious whether the content extends above 20 kHz.   

Google for that hydrogenaudio thread: Reznor made one post on it, and
mentioned that the recording was done at both 24/96 (Lavry) and 24/192
(Apogee) on all songs, and they chose whichever they preferred at mix
time.


> If Flake is only an  
> encoder, and compression levels above 8 are not guaranteed to be  
> compatible, then what's the purpose?  If Flake cannot decode, then  
> what good is it to create a file that no other decoder can handle?

Because it (hopefully) produces compatible FLAC files that can be
decompressed by any FLAC decoder out there. It's still at version 0.11
and is intended as an alternative to the reference encoder. I knew about
it, but didn't try it until it popped up in my Ubuntu package manager
when I was searching for something else.

http://flake-enc.sourceforge.net

The extra stuff it does is variable block size encoding (which is legal
according to the spec, just not implemented in the reference encoder.
If you try the higher compression levels there is a warning that the
files created might not work with all FLAC decoders.

I can understand working on an alternative encoder first, because if it
is to remain true to format, any decoder should always be able to work
on what it creates. The metaflac tool will display what encoder was used
to create any FLAC file.

I was wrong about it going up to 11 - it actually goes up to 12.
But like the reference encoder, those levels are just shortcuts to more
complex options (prediction type, block size, etc). My first test was a
16-minute WAV ripped from CD, encoded at all the compression levels that
Flake has, and then tested using flac -t (and they all passed). However
they were all bigger than what flac -8 produces, so I have done no more
testing.

I really need to throw more varied music at it, then load it all up on a
microSD card and see if any hardware players cannot deal with the higher
compression levels.
But if there isn't an appreciable reduction in size then I won't be
changing over from the reference encoder.


> Every time I see the long filenames  
> issue, I worry that there is a problem, until I remember that this is  
> a known issue and just ignore it.

Thanks, I thought it was just me...


> Anyway, the flac command-line should be improved, even though the  
> file format and library are probably just fine being left alone.

The format should definitely remain frozen: that was one of the founding
principles of the ARJ compressor, after widespread confusion when PKZIP
2.0 was released (older versions of PKUNZIP could not deal with the new
compression methods).

-- 
-Dec.
---