On Fri, Jan 07, 2011 at 02:22:51PM -0800, [email protected] 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. --- _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
