Slashdot Mirror
FLAC Joins The Xiph Family
Ancipital writes "Xiph.org (of Ogg Vorbis fame) have today announced that the FLAC (Free Lossless Audio Codec) project has joined the Xiph rebel alliance. The full story and press release can be found at the Xiph site. (FLAC is nice, because it gives you pristine lossless audio at roughtly 50% size reduction over uncompressed WAVs- you can store them on your hard drive/wherever and then transcode down to a lossy format when you need portability, yum!)"
Yep... zip doesn't do too good with audio data.
There is a Winamp plugin for FLAC already (it has been around since the first time FLAC was on Slashdot, too).
Here's a little meat for you:
2. RESTRICTIONS. Notwithstanding any provisions in this agreement to the contrary, Licensee may not (a) make, use or load into temporary memory any unapproved copies of the Licensed Materials without the appropriate license(s) for use on additional CPUs; (b) distribute the Licensed Materials; (c) modify, transmit, rent, lease or sublicense the Licensed Materials; (d) reverse-engineer, decompile or disassemble the Licensed Materials, except to the extent required to be permitted by applicable law; (e) disclose any source core or performance characteristics of the Licensed Materials to any person or entity; (f) use the Licensed Materials in a service bureau or "application service provider" environment or for the benefit of third parties; or (g) at any time do or permit to be done anything which shall adversely affect SoftSound's right, title or interest in the Licensed Materials. If the Licensed Materials are used within a country of the European Community, nothing in this Agreement shall be construed as restricting any rights available under the EC Council Directive 14 May 1991 on the legal protection of computer programs.
Emmett Plant
CEO, Xiph.Org Foundation
I wish Jeff Gilchrist would add a unix/linux section to the Archive Comparison Test (ACT) page (http://compression.ca). He does have a corpus of sound files, so check it out to see how other compressors are doing (FLAC is not included, though).
Method of processing duck feet
FLAC has been around for a very long time, as a seperate project -- FLAC 1.0 was released in June 2001, for example. The reason for this announcement is that FLAC is joining the Xiph family of completely free (no cost, no patents, no licencing restrictions) media projects. It nicely complements Vorbis, which is Xiph's lossy codec.
You can think of the relationship between FLAC and MAC similarly to the relationship between Vorbis and MP3. It's a slightly strained analogy, but works to a first approximation.
-- Help Digitise the Public Domain at DP.
Here is a table listing many lossless compression techniques, FLAC is there, but it version .1c might be an early alpha, ZIP RAR SHORTEN and most of the other interesting ones are represented here as well.
Bork Bork Bork!!
ADPCM is high bit-rate but still lossy because the "difference" is not coded losslessly. As for gzip, it does not achieve 50% compression on wave files.
Opus: the Swiss army knife of audio codec
Earth to PhysicsGenius! (What kinda login is that anyway?) Ever used zip? Or bzip2? Ever looked at the unzip -v output? It lists compression ratio right there. Try compressing some text files. Or some comma separated files. 50%? Easy! 80%, sure.. That's because of a little thing called redundancy or rather (the lack of) entropy. Look up some information theory..
Tape backup salesmen usually claim 50% compression (actually they just inflate the number of gigs of the tapes). And they get away with it. Just like stacker. Cos most of the time, you get pretty close to 50% with all sorts of data. Audio is really really redundant stuff; thats why a format like shorten (shn) exists; squeezing out the last juicy bits of redundancy - specialized algorithms can usually easily beat 50%.
One example? You can compress some of the most beautiful images in the world in a few lines of code and some parameters.. It's called a fractal. I don't have to send you a PNG; I give you the parameters, and you generate it, given the 'specialized compression algorithm'..
Ok, if you want to get into that, check out (in addition to Information Theory (that Shannon dude) ) some Kolmogorov complexity theory, if you're really interested. But apparently, you're not. Troll.
The upcoming version of AlsaPlayer will support FLAC streaming over HTTP, and even seeking if you use HTTP 1.1. We should see FLAC streaming support in Icecast soon, at least I hope so.
-adnans (*plug*!)
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
I just started archiving my CD collection (350+ discs) using FLAC. I tested a number of codecs, including LAME, Ogg Vorbis, and FLAC.
In the end, I settled on FLAC for four reasons:
* It's completely lossless.
* Gapless playback
* If you save the TOC from the source CD, you can burn an exact copy, pregaps and all, from your FLACs.
* I can reencode to Ogg, MP3 or whatever lossy format I want at any time. Nice for when I want to make a MP3 disc to play on my MP3 walkman, and I don't lose quality like I would if my source material was in Ogg.
Hopefully, we'll see wider support for FLAC come from this partnership. Not too many players support FLAC, though the FLAC developers have made plugins for XMMS and WinAmp.
Oh, and some people have been tossing the '50% compression' thing around already. It really depends on the music. I have managed up to 70% compression on some sparse music, (mainly ambient and classical) while my death metal and noise encoded around 30%. It seems that the more dense the source is, the less it compresses.
Near as I can tell, Monkey's Audio still doesn't work anywhere but on Windows (though support for other platforms is promised). FLAC works on Windows, MacOS9/X, Linux, BSD and even has hardware support. That single platform limitation makes Monkey's Audio difficult to justify for any serious audio preservation.
Ita erat quando hic adveni.
With all of the damn codecs in the world, one that only provides 50% saving is just Not Ready for Prime Time. Somehow, with all of the repetition in music, there has GOT to be a way to do better than that.
I'm sure everyone here would welcome any successes you have in researching this.
Storing in one format and then have to convert to another all of the time just not an option. Maybe when memory is a dollar a gigabyte (and I mean RAM!), them this might be a choice - but I am hoping for something better.
Maybe you're missing the point. FLAC is a replacement for WAV. That is, a lossless way to store sound, and still be able to use it, via. direct playability in XMMS and WinAmp.
If you want small, then use mp3 or ogg, which is for small but lossy files. If, after encoding to mp3, you still keep your old WAV files, in order to be able to re-encode into any other lossy format, then FLAC is useful to convert your WAV collection to -- not as a replacement for mp3 or ogg.
The price of freedom is eternal litigation.
The FLAC format has metadata support, and since you now can put FLAC in Ogg containers, it can also use Ogg tag support which is truly great.
In short: id3 (especially id3v2) sucks and should just DIE as soon as possible. Foobar 2000 even goes as far as to completely forgo id3v2 support on ideological reasons. Honestly, I think they are on to something.
________
Entranced by anime since late summer 2001 and loving it ^_^
This is why (or at least a major reason) lossless audio compression is so hard. There just isn't enough repitition at the sample level to produce a dictionary for your traditional compression algorithms (gzip, bzip2 etc)
Now, if music was as repetative as you thought, we'd be able to compress 90% of the music released in the last 5-10 years to about 1kbyte ;)
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
Simple..
If it takes 650Megs to store 74 minutes of music, at 50%, it should only take 325Megs.
325M x 325CD's = 105625Megs, or 105.625Gigs
This of course is an approximation, since sometimes the compression is better/worse..
Slashdot is like Playboy: I read it for the articles
Speaking of quality increase isn't really the right way to look at it. It's the decrease from the original that is important.
Most poeple, experts included, cannot tell the difference between a 320kbps mp3 and an original 44.1khz pcm sample. I mean, the vast, huge majority of experts simply cannot tell the difference.
But there IS a difference. We know there is a difference because it's lossy compression. We know that when we take an original CD and use flac on it, we end up with an exact copy of the original. That's why lossy compression exists.
If you are simply listening to something on the headphone jack of your computer with medium or low quality headphone (like Bose or most of the Sennheiser line (medium) or the normal crap you buy in any store (low)), you don't have a chance of hearing the difference between a high bitrate mp3 and the original.. there is too much noise from the computer, and not enough power from the headphone jack.
On the other hand, if you are using a clock stabilized external output from a good external soundcard with a proper mixer, running through a good class-A headphone amp and into a good pair of headphones (Sennheiser HD580, HD600, Grado RS-1, RS-2, SR325), in a quiet room built for listening, and if you have good ears, and are used to listening for detail, you may hear a difference.
For the most part, linear prediction. This uses a linear combination of past sample values to predict the next sample value. The difference between the prediction and the actual is Golomb-Rice encoded. Golomb-Rice codes are used when the probability of an integer occurring is geometric (i.e., the value N+1 is 1/R times as likely as the value N, for some R > 1). This is a pretty good assumption for audio, since the predicted values tend to be quite close to the real ones. Some other lossy compression algorithms also use linear prediction, but they quantize the predicted values to reduce the bitrate even further. The quantization is the lossy step.
MP3 and OGG, on the other hand, work differently. They first transform a block of audio using the MDCT, and apply a psychoacoustic model to the resulting spectral envelope. This eliminates a lot of subbands that are "inaudible." At that point the remaining subband energies are quantized and entropy-coded. To decode, the encoded energies are decoded and the spectral envelope is reconstructed, then transformed back into the time domain to become "audio" again.
It would be a serious feat to integrate FLAC and OGG. They are totally different systems.
Say you've got your collection of CDs at home, and you're just about to encode them all for your iPod. "Okay", you figure, "I'm going to pick.. umm.. 192kbps MP3s, since that's pretty good and I'm going to be listening to them over cheap headphones on the train on the way to work."
So you go ahead and encode your entire 600-album collection to 192 kbps MP3s. And you put them on your iPod, and everything's fine... until you decide you want to listen to them at work as well, and 192kpbs just isn't good enough for listening in the quieter environment in your cube.
Now you've gotta take your 600 CDs and re-encode them at 320 kbps, because if you were to do something silly like extract your 192 kbps MP3s to wave files and re-encode to 320 kbps, you'd just end up with inflated 192 kbps MP3s.
Better yet, say you want (vbr) ogg files at work; or Apple (heaven forfend) finally comes out with a portable player with ogg support. You still need to go back to your original CDs (are they scratched yet? Did you lend 'em to your friend and forget he had it before he left for Maryland? Did your wife take your favorite disc to work with her, where one of her students used it for an art project?) and re-encode everything.
Now, say instead you use FLAC (or SHN, or even APE which I've never personally used).
You take your collection to work; turns out your servers are slightly too small for the FLAC files, so you expand to wave and encode to 320 kpbs MP3s using a simple shell script for the entire collection.
You want ogg files for your new next-generation iPod; great, just run a slightly different shell script to expand to wave and encode to ogg.
Your apartment is broken into and your entire 600 CD collection is stolen, including that ultra-rare CD you got from that band that was once part of that other band but split off when the original drummer OD'd, but they only burned 300 copies of their indie CD and besides they haven't been together since '94. No problem, you've still got the FLAC files and can at least burn yourself a virgin, bit-for-bit exact copy (depending on how carefully you originally extracted it, of course) of the audio -- your artwork and individually-numbered disc are still gone, sorry.
And that's not to mention new compression algorithms, media formats, etc. MP3 and any other lossy compression algorithm doesn't handle future-readiness very well.
Not true! While this is true for the Xing encoder which a lot of bad CD-ripper applications use, LAME or the Fraunhofer mp3 encoders do not mangle the sound as much. Try and get a good compile of LAME from HA and do a "lame --alt-preset standard file.wav" and open the resulting wave file in Cool Edit and have it show you the frequency stats of the created mp3. You shouldn't use this for a comparison of sound quality though - your ears are still the only useful tool for that, but what it will show you that you are wrong.
You might have heard of the Nyquist theorem before, which states that when storing audio data using PCM (Pulse Code Modulation) the highest frequency you can have it half the samplerate. Thus there are no frequencies higher than 22.05kHz on a CD (because their samplerate is 44.1kHz).
________
Entranced by anime since late summer 2001 and loving it ^_^
Visit etree.org. The big benefit of lossless compression is it makes for better distribution of live recordings. The short of it is that demanding recordings in a losslessly compressed audio format, along with verification using checksum files, guarantees no loss in fidelity.
There are many alternate live-music trading scenarios which cause a loss in fidelity. Two of the most common: 1) CD Audio->CD Audio copies are not perfect (unless you use a specialized tool like EAC - Exact Audio Copy); 2) trading lossily-compressed audio tends to lead to loss of fidelity through inevitable decompression, writing to CD, reripping, and reencoding.
Calculated, 650 MB per CD times 165 CDs is about 107 GB.
As soon as I can scrape the cash together, I'm gonna buy a large hard drive and keep them on-line for XMMS. Right now I have them compressed to 256MB MP3s with LAME.
Method of processing duck feet
So the point isn't that FLAC is new.
And I'd laugh my guts out if it were.
FLAC isn't new.
Someone set us up the bomb, so shine we are!
Minor point, but the tags are not part of the Ogg container. FLAC implements tags the same way as Vorbis does, as one of the initial packets, so they are available in raw FLAC as well as Ogg FLAC.
FLAC - Free Lossless Audio Codec
I'm reading results from searches of that site for r3mix and up to now all I've come across is people who say the author of of the R3Mix site doesn't know what he is talking about.
No proof for this criticism is given (AFAIK -- but I've only read about 4 or 5 threads on it) so it seems to be to be more of a forum vs. forum flamewar. Sort of like K5 is better than Slashdot and vice versa. Maybe what we all need is for SNUH to get involved and fix the attitudes of both groups. There's no way I will register at boards with those attitudes, though.
I'd love for anyone to point out what is incorrect on the R3Mix site. I'm prepared to defend CDs over vinyl, though, so it had better be better than that.
99% of the bitching seems to be that the r3mix setting doesn't produce the very best audio. Well, of course it doesn't! It's promoted as the best acoustical compromise between space and quality. Even if it isn't the best, the fact still remains that 256 & 320 kbits MP3 are unintelligable to the original by normal human ears, which is what the original poster wants people to know. I suppose if you have abnormal hearing you might tell the difference, you know, like you're a Ferrengi or something.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Not so, they are already integrated, i.e. you can already encode to raw FLAC or Ogg FLAC with the command-line flac encoder. FLAC packets are embeddable in an Ogg container just as easily as Vorbis ones.
FLAC - Free Lossless Audio Codec
People should check out: http://wiki.etree.org, an online network for people interested in live jam band music. They are trying to move towards using all FLAC, or at least mostly. Also check out the etree audio archive, they have some stuff in FLAC, although most of it's in SHN.
Ya know, up to that point, you had a good Anything But Microsoft rant going there. But you missed something. Microsoft Windows Media 9 already has a lossless codec.
This sig intentionally left blank.
You can wrap FLAC in an OGG stream, but why would you want to?
FLAC already has a very good wrapper. OGG is very small, and adds as little as possible to the size of the raw data making up the media stream, but some decisions were made that make OGG useless to me as a wrapper.
As an example, how do you seek in a file?
In FLAC's native format, you read the Metadata Block Seektable which gives you a mapping between points in time, and points in the file.
In QuickTime, you read the Sample Table Atom which does basically the same thing.
In OGG? It appears ( from vorbisfile.c) that you have to seek through the whole stream, reading the headers of every page to find the locations of all of the absolute granule position markers and regenerate the same information that other formats spend a few hundred bytes to store in a table.
Needing to read the whole file before being able to seek might not seem like much, but when you are dealing with files of moderate size (6 hours or so) stored on a media where the transfer rate between the file and the player is close to the bitrate of the audio, it becomes extremely annoying.