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!)"

Comments

huh?

[ldspartan]

And why is this any better (or even interesting) compared to Shorten (.shn) which has existed for years?

I don't find lossless audio / video compression terribly impressive... lossless compression has been studied and worked on for decades.

Re:huh?

[Anonymous Coward]

Why do you find it important to comment about what you don't care about?

Re:huh?

[Deagol]

FLAC isn't just free-as-in-beer. It's Free, complete with source and everything.

I've backed-up about 325 music CDs to CD-R using FLAC. It works as advertised. If you want lossless compression, use FLAC. It even has a XMMS plugin -- I use it all the time.

Re:huh?

[niconico]

...because it is Free (Libre) software ?

Re:huh?

[zoid.com]

How about ID3 tags, seekability, and built in md5 verification?

Re:huh?

[Emmettfish]

Because Shorten is proprietary, that's why. Check out their license.

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

Re:huh?

[Anonymous Coward]

It's better because it has a higher compression ratio overall than Shorten. It doesn't compress as well as WavPack or Monkey's Audio, but there's a good reason for this...

It's also better for some applications because encoding and decoding are asymmetric: Decoding can be done VERY quickly in comparison to encoding. This has advantages in embedded applications, as slower processors can be used, increasing battery life. There's other areas that this is probably useful for as well, but listening to music on your m.n GHz PC isn't one of them.

It's better because it also has hardware support in the form of the PhatBox.

It also supports vorbis-style tags.

The latest version (1.1.0) can also embed cuesheets into the file. With this, you can now back up an entire CD into a single file, simplifying management.

These are all things that make flac better.

Re:huh?

[Anonymous Coward]

flac is streamable, and doesn't have the seek table all the way at the end of the file. i love shorten, but flac is an interesting up and comer.

Re:huh?

[Anonymous Coward]

The compression ratio and time of FLAC is better then shorten.
Compression ratio is surpassed by OptimFrog, but slightly and that codec is very slow.
Monkeys Audio performs the best ofverall, but is not Free as in speech(yes it's free as in beer) and it's windows only.

It makes alot of sense if you don't want to loose any information.
Storage is dirt cheap and is hardly an issue(bandwith could be).

I use flac for ripping and encoding music I own, o that years from now when the polymer of my CD's is starting to break down and the pits become less clear and CD players go the way of the grammophone, I still have exactly the content I purchased.
Also when some codec has transparent audio at 128 kbps(With LAME mp3 transparent audio is at around 190 kbps, command line used is --alt-preset standard, although it differs per person when the audio becomes transparent, meaning you can't tell the diffrence between the source and the priginal) , I just encode from my flac instead of re-ripping all my audio.

Re:huh?

[Inf0phreak]

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.

Re:huh?

[Josh Coalson]

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.

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.

Re:huh?

[nnd]

what about ogg tags is so much better than id3? im just curious as i've heard this a few times without much explanation.

A FLAC!

[Anonymous Coward]

Insurance or open source?

Better than ZIP?

[stevenp]

Does it work better than ZIP???

Re:Better than ZIP?

[Anonymous Coward]

Yep... zip doesn't do too good with audio data.

Re:Better than ZIP?

[Deagol]

Yes, it does.

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).

Re:Better than ZIP?

[brandorf]

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.

Re:Better than ZIP?

[kspiteri]

Since FLAC is designed specifically for audio, it can take advantage of audio statistics, enabling it to compress better. AFAIK general lossless compression programs such as zip perform bad on audio, since audio seems fairly random to them.

Re:Better than ZIP?

[Anonymous Coward]

Not true. zip, gzip & co. do ok with audio. Sound is full of repeating patterns, and depending on what sort of sound you are talking about, you can achieve decent compression. I remember seeing somewhere around 20-40%. Of course the 30-60% compression which you can get with formats specifically designed for audio is much nicer.

Re:Better than ZIP?

[Anonymous Coward]

Me fail English? That's unpossible!

Lossless format

[PhysicsGenius]

Once again, Slashdot is posting wild claims about a new compression scheme. This one claims to have a 50% compression ratio while losing no data. Earth to Slashdot, that's not possible! Either you are getting rid of data (and a filesize that's half the original indicates they are) or you aren't. There's no such thing as "lossless compression" by definition.

Re:Lossless format

[Enry]

Never used gzip/ZIP/bzip2/compress/arj/cab have you?

Re:Lossless format

[brandorf]

"Lossless compression" means that the compression algorythm allows for the compressed file to be reconstructed exactly as it was before compression. You do remove data in compression, but you do it in a way that you can reconstuct the data you lost.

Re:Lossless format

[Neophytus]

Pattern recognision is lossless in a way, where one reference is always referred back to the first occurance. I dont know how this applys to audio files, if I am right at all (I dont know much about compression tbh) but if data compression lost data in the process, then the files spewed out on decompression would be corrupted, no?
Apologies if that doesnt flow together.

Re:Lossless format

[Anonymous Coward]

Lossless means no loss of information, not no loss of bytes, and if you uncompress a flac file you get exactly the same wave file you compressed.
Same as with a zip file.No loss of information, but a loss of bytes.
I can say 2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2
Or I could say 20*2, or just 40.
It's the same information, diffrent amount of characters(bytes).

Re:Lossless format

[spaten-optimator]

Actually, there is such thing as "lossless" compression.

For example, dictionary-style compression (what .zip uses) compresses data by developing a small dictionary of byte sequences that recur in a file, and representing those byte sequences as a single byte, thereby saving space. You develop a large enough dictionary of this type, and you're saving file space.

Zip is living proof that lossless compression exists - you COMPRESS your text files, without LOSING any of the data in it when you DECOMPRESS.

That's what lossless compression is.

For more info, look into the entropy of data, which helps to determine the lossless compressability.

An example of LOSSY compression is mp3 or JPEG, where you (usually) sacrifice some quality for increased compression. Part of what makes mp3 work so well, is that it throws out the parts of the audio signal that are out of the human range of hearing.

--

Re:Lossless format

[Masem]

Yes, there is, but the data has to be ideal for 'compression' to work; Run Length Encoding comes to mind (eg: "aaaaaaaaaa" compared to "10a"). Heck, everyone uses zip and gzip and bz2 files, which are compression, but nothing gets lost, thus lossless.

However, the compression mostly happens for highly idealized data (such as written text); binary files or music/image files where the randomness of successive bits is very high, and thus lossless compression can't happen.

I don't disagree that a lossless compression scheme that gets 50% compression is highly questionable, but it's definitely not out of the realm of possibility.

Re:Lossless format

[Feyr]

actually, he has a point. that is if you look at lossless compression as a "don't throw anything out" point of view. if you think about it, if you really didn't throw anything out, you would'nt get any compression

it doesn't hold its ground in the sense that we usually look at lossless compression. merely, "don't throw anything out, unless you can recover it exactly"

Re:Lossless format

[Anonymous Coward]

Once again, Slashdot is posting wild claims about a new compression scheme. This one claims to have a 50% compression ratio while losing no data. Earth to Slashdot, that's not possible! Either you are getting rid of data (and a filesize that's half the original indicates they are) or you aren't. There's no such thing as "lossless compression" by definition.

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.

Re:Lossless format

[AmunRa]

'Physics Genius' - you obviously have no clue about compression formats! So you loose data when you use a zip/gzip/bzip file? Then why does anyone use them?

OK, if you are arguing semantics, then yes the compressed file has 'lost' some information, but the compression algorithm can recreate that information.

Very simple example: a file that contained 20 'a' s (aaaaaaaaaaaaaaaaaaaa) could be compressed by recording in the compressed file that the file is 20 x the letter 'a'. The decompressor can recognise this and write out the contents of the original file.

You're either trying to be a troll or a know anything about compression - whichever it is, don't bother posting!

Re:Lossless format

[Azar]

While I believe the parent post to be nothing more than a troll/flamebait, I'll bite.

Either you never studied compression or never fully understood it. There are two basic types of compression: lossy and lossless. Lossless means that none of the original data is lost. This doesn't mean that the compressed version is -identical- to the original. It simply means that by following a predetermined algorithm, the original can be fully restored. Compression schemes look for repeating patterns. The more common a pattern is, the better a compression ratio you will acheive. Common repeating patters are replaced by some sort of symbol or mapping (which is saved with the compressed file). To reverse this you simply replace the symbol or mapping with the original sequence of characters.

If you take a file, make a copy, compress it using lossless compression, and decompress it to a different filename the computer will find no differences between the two. The compressed/decompressed copy will look -identical- to the orignal. That's what's meant by lossless encoding.

By claiming " There's no such thing as 'lossless compression' by definition" you are only showing your ignorance.

Re:Lossless format

[Anonymous Coward]

Tried it often on audio. NEVER seen anything normal file comressor give better compression on real audio files. And that's the point, FLAC works better than zip,bzip2,rar etc. on audio.

Re:Lossless format

[acidrain69]

"Lossless means no loss of information, not no loss of bytes, and if you uncompress a flac file you get exactly the same wave file you compressed.
Same as with a zip file.No loss of information, but a loss of bytes.
I can say 2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2
Or I could say 20*2, or just 40.
It's the same information, diffrent amount of characters(bytes)."

Actually what you represented isn't lossless. Yes, the sums are the same, but the string of 2's is lost in the 40 representation. 20*2 is valid tho, as long as you have some way of knowing that it spans to a summation of 2's. Otherwise it could just be 20+20.

Re:Lossless format

[Anonymous Coward]

This is a little off. The modeling used by mp3 and ogg do far more than just "throw out the parts of the audio signal that are out of the human range of hearing."

Are you saying that the CD's people are encoding to mp3 have "inaudible" sounds on them?

I didn't think so.

Re:Lossless format

[Anonymous Coward]

> actually, he has a point. that is if you look at lossless compression as a "don't throw anything out" point of view. if you think about it, if you really didn't throw anything out, you would'nt get any compression

Actually, he doesn't. Lossless compression schemes work by finding long strings of repeated data and representing that long string in a much shorter form. No information is thrown out, just changed in format - ALL the information is still there so when it's uncompressed you get an exact copy of what you started with.

Re:Lossless format

[ShadeARG]

Lossless compression doesn't "throw" anything out, it just rearranges the data so that redundant sequences can be represented in a smaller amount of space. Take a look at this. It simplifies how this type of compression is achieved.

Re:Lossless format

[spaten-optimator]

Are you saying that the CD's people are encoding to mp3 have "inaudible" sounds on them?

I didn't think so.
--
Actually, that is what I'm saying. I did dumb it down a little, but if you'd like to learn how mp3 compression works, check out this site.

A quote from this site:
To make a good compression algorithm for sound, a technique called perceptual noise shaping is used. It is "perceptual" part because the MP3 format uses characteristics of the human ear to design the compression algorithm. For example:

* There are certain sounds that the human ear cannot hear.
* There are certain sounds that the human ear hears much better than others.
* If there are two sounds playing simultaneously, we hear the louder one but cannot hear the softer one.

Using facts like these, certain parts of a song can be eliminated without significantly hurting the quality of the song for the listener.

That is to say, parts of the audio signal (the parts that are inaudible to the human ear) are removed to save space.

After that is done, a regular compression algorithm is applied to the file, further reducing the size.

Some of the major dissidents of the mp3 format claim that these so-called "inaudible sounds", when removed, can affect the overall quality of the audio. I guess that's why they wanted a lossless compression algorithm in the first place. Actually, a lot of these people don't like digital transfers of music at all. They prefer an analog technology like vinyl.

For most people, though, the difference in quality is negligible, at best - especially when compared to the savings in data space.

Re:Lossless format

[Read Icculus]

Questionable you say? Well to answer your question make an md5 of your favorite wav file, now compress said wav file with FLAC. Now get rid of that original wav file, (mv, rm, or shred -vuzx -n 1000... your choice). Now you have a FLAC file that's ready to decompress, do so, and then check it against your md5 file of the original wav. There's your answer.

Re:Lossless format

[NeMon'ess]

It was a troll, so why did you bite? You and fifteen other people who said the same thing before you did. Did you think you were adding something constructive that none of the other 15 had thought of? You had to read the troll to know what to say, so why didn't you read the responses below. You and everyone with your lame mental abilities are why trolls still live on /. Its just too easy to troll sometimes.

By posting "I'm a fool who doesn't read other posts" you are only showing your ignorance.

Re:Lossless format

[raygundan]

You don't get 50% compression with zip. The algorithms in traditional data compression software are not well-designed for working with sound files. I don't know the mathematical details of why, but I have tried it.

Re:Lossless format

[Anonymous Coward]

There's no such thing as universal lossless compression. If you take arbitrary sets of random data, you can't compress all of them.

We're not talking about random data tho, we're talking about sound that humans want to hear. Very little data that humans are interested in is truely random, most of it can be compressed without loss.

Re:Lossless format

[Elwood P Dowd]

Earth to PhysicsGenius! (What kinda login is that anyway?)

It's a troll kind of login. You guessed right. He's been at it for a while.

Re:Lossless format

[saintlupus]

It's a troll kind of login. You guessed right. He's been at it for a while.

Yeah, but at least he's entertaining. I'd rather have a ton of trolls like PhysicsGenius, tps12, and Amsterdam Vallon rather than the crapflooders and idiots that end up at -1 seconds after posting.

"Trolling" is an art form, to be honest, and it's great to watch him still get so many bites.

--saint

This reminds me ...

[Anonymous Coward]

of html.

Stop giving me...

[webword]

FLAC about MP3!

New?

[brandorf]

I don't see why FLAC is so cool, there has been lossless Audio Compression for some time now, in the form of Monkeys Audio Codec or MAC, it's been around for at least 2 years now, and gets the same compression ratio FLAC claims. Even better is that there is a winamp plugin to play them already. Though I will give FLAC credit, because it just sounds cool

Re:New?

[fredrikj]

There is a Winamp plugin for FLAC already (it has been around since the first time FLAC was on Slashdot, too).

Re:New?

[jonathan_ingram]

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.

Re:New?

[Anonymous Coward]

Well, that codec wasn't quick enough to get itself into the Ogg project, then. That's what makes FLAC better: it'll be part of a standard for the next 100 years, whereas the codec you mention, will be obscure unless somebody who cares makes it happen.

Winning is a virtue in itself. Winners win. Today, FLAC became a winner.

Re:New?

[abimelech]

Foobar 2000 for Windows has been able to play OGG FLAC files, which are FLAC encoded files in the OGG file wrapper format for a while now (since it was released in december 2002), so it seems this partnership is slightly more than just political.

Re:New?

[tuffy]

I don't see why FLAC is so cool, there has been lossless Audio Compression for some time now, in the form of Monkeys Audio Codec or MAC, it's been around for at least 2 years now

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.

Re:New?

[Anonymous Coward]

Yeah, cause Windows is likely to disappear from the face of the earth sometime in 2004, when Linux takes over completely.

Isn't it nice to be delusional!

Re:New?

[Anonymous Coward]

Yeah, cause Windows is likely to disappear from the face of the earth sometime in 2004, when Linux takes over completely.
Isn't it nice to be delusional!

Umm.. ok.. Yeah, cause everyone uses Windows to listen to music.

Re:New?

[tuffy]

Yeah, cause Windows is likely to disappear from the face of the earth sometime in 2004, when Linux takes over completely.

Isn't it nice to be delusional!

About as delusional as assuming everyone has Windows installed. Where's the advantage in using a Windows-only format over one that works both on Windows and everywhere else?

ADPCM?

[ecloud]

What about that? What about adaptive delta coding, is that the same thing as ADPCM? I just know that ADPCM is already supported in WAV files and has been for years. Maybe it has strings attached though.

Even gzip might be able to achieve 50% compression, right? I wonder why they can't achieve higher ratios?

Re:ADPCM?

[jmv]

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.

Re:ADPCM?

[Anonymous Coward]

Basically because it gets tough to get better compression while finishing in a reasonable amount of time.

gzip can probably achieve 2:1 on files that lossless audio compressors get closer to 4:1 on.

Re:ADPCM?

[jonathan_ingram]

ADPCM is not lossless. It is a non-perceptual lossy method of encoding audio. Contrast this with MP3, which is a perceptual lossy encoder, and ZIP which is a non-perceptual lossless encoder.

'Perceptual' means that the method has some model of human hearing, which means that it can more easily discard data which the human ear can't hear.

'Lossy' means that the encoded data is not an accurate representation of the original.

Generally, non-perceptual lossy audio codecs represent an old generation of technology -- they take up less processing power than perceptual codecs, but cannot compress audio as efficiently as perceptual codecs.

Re:ADPCM?

[Anonymous Coward]

I admit I only have a sample size of one, but...
$ gzip -9 -c dooropen.wav > /tmp/tmp.gz
$ ls -l /tmp/tmp.gz
-rw-r--r-- 1 nemo users 10044 Jan 29 13:55 /tmp/tmp.gz
$ ls -l dooropen.wav
-rwxr-xr-x 1 root root 19180 Sep 30 15:47 dooropen.wav
That's 52.4%

Pretty close.

*yawn* And almost everything out there seems to include zlib. For sheer convenience, rather than worrying about my wav files, going to just keep on tar.gz ing stuff.

Re:ADPCM?

[Anonymous Coward]

Losslepss "perceptual" codecs probably just have a predictive model that encodes common sounds more efficiently than bizzare or unrealistic sounds (a counting argument tells us you can't make any files smaller without making some at least a little bigger, though those are the ones you may not care about in practice). If it actually discarded information because it can't be perceived, it would be lossy.

Re:ADPCM?

[Anonymous Coward]

You are using a 20kB wav file. A four-minute song ripped from a CD is more like 40MB. gzip hardly puts a dent in files of that size. Don't take my word for it though--run gzip on a few 30MB+ wav files and see what kind of compression you get. It ain't much.

Re:ADPCM?

[Anonymous Coward]

I admit I only have a sample size of one, but...
$ gzip -9 -c silence.wav > /tmp/tmp.gz
$ ls -l /tmp/tmp.gz
-rw-r--r-- 1 nemo users 105 Jan 29 13:55 /tmp/tmp.gz
$ ls -l silence.wav
-rwxr-xr-x 1 root root 19180 Sep 30 15:47 silence.wav
That's 0.524%

Take that.

*yawn* And almost everything out there seems to include zlib. For sheer convenience, rather than worrying about my wav files, going to just keep on tar.gz ing stuff.

Re:ADPCM?

[JebusIsLord]

I just tried with a real song... 'Where is my mind?' by the Pixies:

41.184 MB wave source file.
36.780 MB using gzip with -9 (11% compression).
32.937 MB using bzip2 with -9 (20% compression).
25.713 MB using FLAC (38% compression).
5.221 MB using LAME with -V3 (87% compression).

Yeh i know the mp3 is lossy, but this one is essentially indistinguishable by the human ear so I thought I would at least add it to the above list.

Re:ADPCM?

[jmv]

0 MB using "rm" (100% compression)

The whole point of FLAC is not good quality, but *lossless*. You could get (e.g.) a studio to use FLAC, but never MP3 or Vorbis, even at highest quality.

Re:ADPCM?

[JebusIsLord]

I know, i agree, I tried to make that clear in my post. Lossless is cool, I just had the #s there in front of me for MP3 as well so figured "why not post them"?

finally

[Boromir son of Faram]

It's great to see something available for those of us who want to record our favorite music to hard drive, but don't want the low quality and artifacts of lossy formats like mp3 and ogg. Even 256kbps mp3s are noticeably worse than CDs when listening to certain types of music.

I'm also a little curious as to why they've gone and reproduced all of this work rather than just using gzip or bzip2, which frequently achieve compression rates of 50% or more.

Either way, I urge all of you to consider lossless compression of music data. Lossy compression is a great burden for one person to bear, and there are other options.

Re:finally

[sixseve]

Try using bzip2 or gzip on a WAV file, you won't get 50% compression.

Re:finally

[Echnin]

Even 256kbps mp3s are noticeably worse than CDs when listening to certain types of music.

300 "audiophiles" disagree with you.

I don't see a need for lossless compression. LAME MP3 with the r3mix preset sounds perfect to me, and anyone who thinks that they can tell a difference between that and CD audio is only saying that to impress people.

Re:finally

[Anonymous Coward]

LAME MP3 with the r3mix preset sounds perfect to me

Ten bucks says you listen to Lincoln Park, Rage Against a Machine, Limp Biscuit, or some other band sufficiently noisy to disguise compression artifacts.

Any music with rapid changes in dynamics and harmonics is going to have some artifacts when compressed with a lossy algorithm. I don't care what bit rate it is; if you are listening to certain music at a high enough volume, and with good enough speakers, you will hear the artifacts. That's why people are working on lossless audio compression in the first place, Einstein.

anyone who thinks that they can tell a difference between that and CD audio is only saying that to impress people

Who would someone with the nickname "Boromir" be trying to impress by posting on Slashdot?

Re:finally

[Anonymous Coward]

Lossy codecs are mostly incompatible with editing (some splicing, all mixing)--every pass would add artifacts until the content has been severely mangled.

Re:finally

[Cuthalion]

That's why people are working on lossless audio compression in the first place,

People are working on lossless codecs because: (I probably forgot some reasons)

• There are people who think that 256kbps MP3 isn't good enough. Whether they're right or wrong, they'll still use a lossless codec.
• If you're iteratively processing stuff (transcoding, editing, mixing, etc) it's way better to do the lossy step only once than each time. Just 'cause 1 iteration may be unaudible doesn't mean 5 will be. (indeed, transcoding is one of the best ways to bring out compression artifacts!)
• It's interesting. I write lots of code that nobody else necessarily wants. For fun.
• Seamless play. Mp3 by its very nature will cause a pop or blip or something if you rip, say two consecutive tracks from a continuous mix into two files, and then encode them. (nevermind the fact that most players don't even try to avoid extra gaps) It might be possible to get it right if you engineered your whole ripping process around it (rip an extra mp3 frame of overlap on each file and then throw out that frame once you've done the encoding?) but I don't think anyone's done that.

Re:finally

[nicsterrr]

I took a random cd track and got the following with bz2 and gwip:

wav 26.2MB
gz 24.5MB
bz2 23.4MB

so it seems they are almost useless for lossless audio compression.

Re:finally

[ncc74656]

If you're iteratively processing stuff (transcoding, editing, mixing, etc) it's way better to do the lossy step only once than each time. Just 'cause 1 iteration may be unaudible doesn't mean 5 will be. (indeed, transcoding is one of the best ways to bring out compression artifacts!)

I'd like to use a lossless audio codec for video capture and editing for this reason. Unfortunately, it doesn't appear that any of these lossless compressors are set up so they'll work as audio codecs inside video editors. I can use Huffyuv to compress video without loss; why aren't FLAC and its competitors available as ACM codecs so that content compressed with them can get stuffed inside a WAV or AVI?

Until then, I guess I'll just have to stick with uncompressed audio...when 1 hour of Huffyuv-compressed D1 video takes 20-25GB, the 605MB that one hour of CD-quality audio takes isn't much by comparison.

Re:finally

[bigberk]

I don't see a need for lossless compression.

You might not need it, but many others do. Certainly, if you're the "audience" at the end of the development/production line, lossy compression is fine.

On the other hand, if you produce digital works and you want to store data that could later be used as source material for a new project, you want to store the work at its original full quality. Otherwise, every time it is re-used the quality degrades. Sure, it's not as bad as magnetic tape degredation but eventually it adds up.

And that's why you need lossless audio (and vide, etc.) storage.

Missing the Point

[dewboy]

I think many posters are missing the point of the article. My first reaction was also "hey, this is nothing new -- SHN (Shorten) has been around for a long time and does lossless encoding at 50% the size of WAV"... but then I actually went to the Xiph site and read their mission:

"Xiph.Org Foundation is a non-profit corporation dedicated to protecting the foundations of Internet multimedia from control by private interests. Our purpose is to support and develop free, open protocols and software to serve the public, developer and business markets."

So the point isn't that FLAC is new... the point is that FLAC is OSS, and has joined forces with an organization backing such efforts. The SHN codec is not OSS.

Re:Missing the Point

[Ziviyr]

So the point isn't that FLAC is new.

And I'd laugh my guts out if it were.

FLAC isn't new.

Re:Missing the Point

[Daniel Phillips]

So the point isn't that FLAC is new... the point is that FLAC is OSS, and has joined forces with an organization backing such efforts. The SHN codec is not OSS.

It's not only that. The FLAC format is better too, for example, it embeds the checksums inside the file (duh!) and includes mp3 tags (double duh!). It has slightly better compression as well. So the bottom line is, not only freer, but better.

Yawn..

[grub]

If you take your LPs out of the cardboard sleeves you easily save over 50% space.

Re:Yawn..

[Anonymous Coward]

Unfortunately that's LOSSY compression, as anyone who's stored an LP without a sleeve for a few years will tell you!

huh?

[bitweever]

FLAC? Xiph? Ogg Vorbis? Narf!

Try saying that out loud, see what your co-workers do.

Re:"rebel alliance"?

[four2five]

I think your equating two different things. The "rebel alliance" comment doesn't have to be construed as a statement of superiority. It could easily be seen as them fighting the reigning superpower, M$, which they are. There is a big difference between striving, as the underdog, to put out a decent product and holding ignorant, grade school attitudes. You seem pretty quick to get huffy about the post, why the resentment?

FLAC streaming

[Adnans]

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*!)

Re:FLAC streaming

[Jugalator]

We should see FLAC streaming support in Icecast soon, at least I hope so.

I'm not sure your ISP hope so, though. :-)

Re:FLAC streaming

[JohnFluxx]

Why would you want to stream and seek etc in an lossless music file?

If you want to send the music to someone, ftp or whatever.

If you want to stream music radio-style, then compressed is 'good enough' - surely?

Great... but what about 3rd party support?

[Zathrus]

This is good news in a nebulous sense, but what about actually getting 3rd party adoption? How many players out there support FLAC? Or even Ogg Vorbis?

I've been contemplating a digital audio player like the Turtle Beach AudioTron for awhile now, and while the AT has better support for a variety of formats than most, it's missing both FLAC and OGG (and the developers have stated it's not coming due to lack of CPU power).

I'd love to encode all my CDs onto a central server and have several units around the house playing from that. But I'd rather not rip around 1000 CDs more than once. And it's still not cost effective to just store them as WAVs - using FLAC would double the capacity.

Yeah, I know... Samba can translate files on the fly now, but that requires a good bit of horsepower. The Celeron 300A in the server just isn't going to be capable of transcoding FLAC->anything in real time, much less do it for 2 or 3 streams at once.

I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support? Is it technical, financial, or what? And what can Xiph do to help them in this?

Re:Great... but what about 3rd party support?

[XanC]

I wouldn't be surprised if your lowly Celeron could decode FLAC in real time, even multiple streams. It takes extremely little processing on the decoding end; it may even be less than MP3 because it's less compressed. I can't say that I've tried it on a 300MHz chip, but I'm pretty sure it wouldn't have any trouble (on linux, anyway).

Re:Great... but what about 3rd party support?

[joe_bruin]

well, the kenwood music keg and phatnoise phatbox support both ogg vorbis and flac (in addition to mp3 and wma). flac has turned out to be the best way to keep single session recordings (ie, concert recordings) continuous without gaps on digital music players. i'm guessing we'll be seeing more firmare upgradeable devices start adding support for flac real soon now.

Re:Great... but what about 3rd party support?

[Bill Currie]

As far as I can tell, my `lowly' Celeron 450 doesn't even notice flac decoding. (dual 300a, but hey:)

Re:Great... but what about 3rd party support?

[dabadab]

According to this comparison, it takes about 7:00 - 7:15 to decode 70:12 long audio on a PII-333, so I would guess that your server could - in theory - serve something like 8 streams at once (in practice with the IO overhead and with a security margin it should not be a problem to server those 2-3 streams at once).

Re:Great... but what about 3rd party support?

[Josh Coalson]

This is good news in a nebulous sense, but what about actually getting 3rd party adoption? How many players out there support FLAC?

There's a list on the sidebar of the FLAC homepage.

I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support?

In the case of the AudioTron, they are getting the full court press from Microsoft to do WMA lossless, and knowing Microsoft this will be to the exclusion of all others. I made a good case on their mailing list that with moderate work (and I was willing to help), the AT would be able to decode FLAC natively. Their response has always been "we tried it and it's not fast enough", despite the fact that identical hardware in other devices (Rio Receiver, PhatBox) can decode FLAC fine.

But no matter, other manufacturers are providing a choice, and the list is growing. Recently the ReQuest guys have added FLAC support to their ARQ boxes. So time will tell what consumers really want.

Re:Great... but what about 3rd party support?

[hetfield]

It's not a player, but I noticed during the install of Unreal Tournament 2003 that the sound files had a .ogg extension. Commercial support is coming, albeit very slowly.

The reason it takes "CPU power" to add new codecs like FLAC or OGG is because the onboard mp3 or wma decoder is hardware. In order to play other formats the decoding work has to be done by the unit's processor. The people who are working on the project to provide an OSS firmware for Archos devices have stated this as their reason why they aren't planning on adding OGG support to their project. There needs to be a hardware FLAC/OGG decoder thats cheap and easy to program for. Does such an animal exist?

Re:Great... but what about 3rd party support?

[josefgabriel]

Yes. I have a Music Keg myself. They guys over at Phatnoise (the makers) are very cool. Just some UCLA Engineers who happened to be MP3 fans and wanted a better car solution. The new version of thier excelent music management software has built in support for encoding FLAC files. I am a DJ so it is a good way to listen to a mix without having gaps between tracks. I currently have a mix of MP3 and FLAC files in my "keg" but am going to try out ogg soon.

Re:Great... but what about 3rd party support?

[John Whitley]

I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support?

Not much. Xiph offers ported and optimized fixed-point code for Ogg Vorbis to anyone who wants it on royalty-free terms (BSD or similar license IIRC). Moreover Xiph has been actively promoting its standards and codebases directly to the involved businesses.

Nevertheless, the trick is actually getting the end-product companies to make Vorbis/FLAC support a requirement for their next product/revision. I suspect it'll be Apple or a similar market leader that forces the hand of the competitors, since it seems that most marketing departments can't see further past their noses than their competitor's feature lists.

Re:Great... but what about 3rd party support?

[NightHwk1]

The thing I'm missing from all these open source media projects is direct audio CD burning.

I spent hours yesterday looking for an app that will go from OGG to CD audio directly, and all I could find was a crappy shareware program called Ashampoo BurnYa! -- and its only available for windows.

And ahead.de ignores my requests for OGG support in Nero...

Re:Great... but what about 3rd party support?

[Nexx]

ISTR my 90MHz Pentium had little problems decoding mp3's (mind you, doing anything else was rather painful, and I think the mp3's in question were topped at 129kbps). However, a friend's P-75MHz had issues with stereo streams.

Re:Great... but what about 3rd party support?

[evilviper]

Using ogg123 and cdrecord, it would be easy to create a shell script that will allow you to burn ogg files to an audio CD on-the-fly. Just as a quick, crappy example:

for OGG in [ 1.ogg 2.ogg 3.ogg ]
do ogg123 --device=wav $OGG -f - | cdrecord -nofix -
done
cdrecord -fixate

Now, if I gave a damn about windows, it woundn't take 20 minutes to make an installable bundle that installs cdrecord, ogg123, the cygwin libs, and a the shell script that can be run (easily and interactively) from the command-line. It wouldn't take much longer to write a simple GUI front-end for it either.

Re:Great... but what about 3rd party support?

[evilviper]

How many players out there support FLAC? Or even Ogg Vorbis?

Flac has plugins for a good number of media players (eg. XMMS, Winamp), and Ogg is supported by every single self-respecting media player. I think Winamp is the only hold-out on natively supporting Ogg, but that is comming in their next version (Winamp3).

it's missing both FLAC and OGG

Yes, few hardware players support even Ogg at this point... However, you act like that is just a fact of life. You see, DivX/MPEG4 has been finalized for much longer than Ogg, yet only recently have DVD players begun to support DivX. Ogg support has been promised by 3 different portable MP3-player manufacturers, unfortunately none give any hard facts (such as a date) as to when support will be ready. Look at the ammount of time that passed before CDs caught on... before MP3 was in a portable player... and you will see that it just takes some time for these formats to be added to hardware products.

what's holding back consumer electronics companies from implementing OGG and FLAC support?

For ogg, it's purely time. They haven't had enough time to get Ogg support ready. Of course, more consumer requests may convince them to add more personel to the job, so fire up your email.

<RANT>
As for FLAC, I doubt there are many interested people. The reason MP3 is so popular is because it allows an entire CD to fit in 64MB at fairly good quality. Tell people that they can get slightly better quality if they are willing to use up 5X the space, and see how few give a damn. The only people interested would be professionals, and they aren't likely to care about having a portable player for FLAC anyhow (and why should they? WAV is supported by most every player).

On the other hand, ogg sounds identical to the original lossless source at 64Kbps, even for audiofiles. That's a genuine improvement for a large nuber of people. Not only is ogg half the size of 128kb MP3s, but it sounds FAR better. I can't imagine anyone will be very interested in FLAC when Ogg is already so very great.

As to the issue of re-encoding Ogg, provided that the lossy source is ogg, and the destination is ogg, there shouldn't be much problem with quality. In theory, the second compression should throw away the same information that the first compression did, hence not decrease the quality at all. That isn't the case when using two different compression methods (eg. MP3 to Ogg), but even then the quality should not drop much.

As for archiving, I don't really understand the desire for lossless compression. Personally, I archive the originals, and put all the wear and tear on the copy, so I have the best of both worlds... A lossy version (Ogg) that sounds perfect and is far smaller, which I can take with me, as well as the original lossless version archived in case I need it (the Ogg version is damaged or I want to reencode with something else). I'd still be happy archiving the Ogg versions, since it sounds just as good as the original. The fact that some information is lost is only a problem in theory.

Re:Great... but what about 3rd party support?

[Ancipital]

On the other hand, ogg sounds identical to the original lossless source at 64Kbps, even for audiofiles. That's a genuine improvement for a large nuber of people. Not only is ogg half the size of 128kb MP3s, but it sounds FAR better. I can't imagine anyone will be very interested in FLAC when Ogg is already so very great.

Leaving aside the fact that ogg itself doesn't sound like anything (it's a container, vorbis and FLAC are codecs :), if it "sounds identical" to you you're either encoding some very odd sources, are playing back on a builtin speaker on a PDA or need to get your ears checked :-)

Honestly, 64k sounds nothing like a full bandwidth signal, with moderately complex content. Vorbis is a lossy coder that makes some rather clever decisions about what to throw away, but even the Xiph team wouldn't dream of saying that it "sounds identical", even at 192k (sorry Monty, around -q 5, shame on me). There are enough fantastic things about this codec for the truth to be sufficient. Misleadingly positive hyperbole is as damamging as misleadingly negative flames, "just the facts, ma'am".

Might I suggest you get a slightly better audio setup (plug your computer into your hifi, failing anything else), and consider dropping a few currency units on a cheap audigy or something else that offers equivalent low-end bang for buck?

Maybe there's nothing wrong with your equipment or ears, some people need a bit of help to get the knack of listening critically. It's a blessing and a curse; I find it hard to use my NexII now since I can hear mp3 artifacts all over the place..

Anyway, with the greatest of respect, I think your argument is based on a manifestly specious premise. I'm sure it's not done through spite or because you're part of an evil conspiracy bent on world domination[*], just that you haven't really got your head around audio. Might be worth learning if you don't value your sanity too highly.

Sorry if this reads at all like a flame, it's not meant to be, and is posted with the best motives, no offense is intended.

[*] I'd have seen you at the meetings :-)

Re:Great... but what about 3rd party support?

[NightHwk1]

Have you tried this?
I was reading oggdec.html, and it says:

Writing WAV format to stdout is a bad idea. WAV requires a seekable medium for the header to be rewritten after all the data is written out; stdout is not seekable.

Re:Great... but what about 3rd party support?

[evilviper]

Have you tried this?

Yes. I've used it a few times.

Re:Great... but what about 3rd party support?

[evilviper]

if it "sounds identical" to you you're either encoding some very odd sources, are playing back on a builtin speaker on a PDA or need to get your ears checked :-)

"odd sources"? That's a bit vague so I can't really argue. What I can say is that, for my encoding tests, I use a handful of very complex song which have demonstrated acoustic problems with other lossy codecs I've tried (MP3 at high bitrates, AAC, TwinVQ, etc). They all sounded identical to the source at -q 0 with Vorbis-1.0 (higher bitrates were required for previous releases of Vorbis). I seriously doubt there is anything wrong with my ears or speakers/soundcard since I DO hear defects in other codecs.

even the Xiph team wouldn't dream of saying that it "sounds identical", even at 192k

As a matter of fact I was just reading the results of a double-blind audio test where many people picked the 128k Vorbis file as the original over the WAV itself, and most picked it as second to the WAV. I'll have to do some searching to find it again, but, IIRC, it was either part of, or linked to from Vorbis.com/Xiph.org.

consider dropping a few currency units on a cheap audigy

I'll stick with my SB Live for now.

All I can say is that ALL of your assertions are incorrect. I have a great audio setup, and the fact that I can hear the artifacts of other codec certainly provides good evidence that I have a good ear... There is the improbable chance that the half-dozen songs I did the serious testing with are murder for other codecs, and perfect for Vorbis, and yet the defects in my 20GBs worth of CDs were just not bad enough that I would notice a single one of them, but that's clearly unlikely.

[*] I'd have seen you at the meetings :-)

You wouldn't know if you had. It's not like I have "evilviper" tatooed across my forehead... It somewhere else entirely.

Re:Oh, boy, yet another codec....

[wzm]

They are working on a lossless codec. This means that your sound quality would be exactly the same as the source, whether it be CD, DVD, or something else. MP3, Ogg, and all the other commonly used codecs are lossy, which means that they are of lower quality then the source file.

Whether or not the world needs another lossless codec is another matter entirely, but this project has a different goal then producing yet another MP3 competitor.

(Yes, that may have been a troll, but someone reading this probably managed to get confused in one way or another)

Very very cool

[Phexro]

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.

Re:Very very cool

[Ed Avis]

There was a Slashdot article a while back mentioning Ogg Vorbis 'peeling'. Like interlaced GIFs (or those weird blocky JPEGs whose correct name I don't know), the first part of the file is a low-quality version and then downloading more bits gives progressively higher quality.

I wonder if FLAC could be adapted do this too, so you could 'head --bytes 1000000' to get a lossy version. Okay, maybe not quite such good quality as an Ogg Vorbis file of the same size, but it might be good enough.

Re:Very very cool

[Coward, Anonymous]

Like interlaced GIFs (or those weird blocky JPEGs whose correct name I don't know)

Progressive jpegs.

Re:Very very cool

[diggem]

Makes perfectly good sense if you think about it. The "thicker/heavier" sounding stuff has more going on, therefore more randomness. Compression theory tells us that a truely random sequence can't be compressed even by one bit without losing something. The more random the music the more truely random portions there will be. The fuzzed screaming or heavily fuzzed guitars would be pretty close to truely random data and therefore is less compressible.

Re:Very very cool

[Anonymous Coward]

If you save the TOC from the source CD, you can burn an exact copy, pregaps and all, from your FLACs.

Any HOWTO's on this? I've been interested in archiving my CD collection (1000+ CDs) for a while now, and I would love to be able to "reconstruct" any CD on demand.

Re:Very very cool

[Phexro]

Use cdrdao, e.g.

'cdrdao read-toc thedisc.toc'

I usually add CD-TEXT information, since most of my discs don't have CD-TEXT:

'cdrdao read-cddb thedisc.toc'

Then, when you want to burn the disc, decode all your FLACs to e.g. track_xx.wav (or whatever is specified in the TOC file - you may need to edit the TOC) and:

'cdrdao write thedisc.toc'

Re:Very very cool

[Anonymous Coward]

Most death metal is pretty dense.

Re:Very very cool

[Phexro]

While this sounds cool, there's really not much point. FLAC decoding is very fast. When I want a MP3 to take with me, I just reencode it:

flac -c -d flac_file.flac | lame - >mp3_file.mp3

It takes under a minute to reencode a typical 4 or 5 minute track this way on my 1.7ghz P4. Just decoding the track takes around 7 seconds, and reencoding it with lame takes 50 seconds.

I suppose it could be faster, but it works for me.

Re:Very very cool

[William Tanksley]

FLAC couldn't be adapted to this, because it's intrinsically lossless; converting it to lossy would require a full conversion, might as well just re-encode it as Ogg.

HOWEVER, it's possible that Ogg could be adapted the other way, adding another layer to it to make it lossless (probably by computing the difference between the lossy result and the actual source, and compressing the resulting stream). The result would be larger and MUCH more computation-demanding to play than FLAC, but it would be lossless and peelable.

I don't have any idea how much larger or more computation-dependant it would be.

-Billy

Re:Very very cool

[cameldrv]

The problem is that at least for MP3, and I believe for vorbis, you discard phase information because you can't hear the phase. This means that just taking the difference of the outputs is going to yield a file that is just as big as the lossless file itself.

Re:Very very cool

[Ed Avis]

I thought progressive JPEGs were the kind where it loads from top to bottom, so if you download half the file you get the top half of the image. But I think I've also seen a kind where it does a first pass in really fuzzy detail, then later passes improve the image quality. Are these two the same thing (or am I just imagining things)?

Re:Very very cool

[Pathwalker]

The multi-pass jpegs are progressive.

The ones that load from the top down are the normal ones.

Re:Very very cool

[William Tanksley]

Yes, the file will be just as big; however, the contents of the file will be compressible on their own, and they'll also be correlated to the contents of the lossy layers (since a wavelet will only appear in the lossless layer if a wavelet generated by the lossy layers blocked it out).

With all that said, though, I'm not confident that it's worth the time. An audio server serving a HUGE number of clients with unpredictable needs might possibly benefit from the CPU savings inherent to this, but such a server would not be legally possible right now anyhow; by the time it's possible, it's almost certain that P2P technology similar to BitTorrent will be more useful.

And my home collection won't benefit; I'd rather use the most space-efficient means, not something to save CPU power for my rare format conversions. So FLAC wins (well, right now, for me MP3 wins).

-Billy

Re:Very very cool

[Ed Avis]

The advantage in peeling might not be the CPU time so much as making things easier to download. If you are streaming music and there is a temporary network outage, a peeled format can continue but at a lower quality until it catches up. OTOH, the peeled format would need to download slightly more before it could start playing at all, since it is no longer the case that the first 10% of the piece is in the first 10% of the file. And the initial few seconds of music would be of noticeably lower quality, unless they were given special treatment. But still it might make a more robust system for distributing music files.

Imagine - keep downloading until you can no longer hear any distortions in the sound, then stop the download. People with less sensitive ears would no longer need to pay the same high bandwidth bills as 'audiophiles'. And you wouldn't need to choose a bit rate before starting your download.

Re:Very very cool

[Anonymous Coward]

So are most ACs.

Algorithms?

[crow]

So what sort of compression algorithm does FLAC use?

One idea that would be really cool is if they could get acheive lossless compression by noting the differences between the original and the .OGG, and appending that to the .OGG. Then if you can just strip off the added info when you make copies to restricted-space devices. The only question is whether this can be done with a competitive compression ratio.

Re:Algorithms?

[foolip]

While this is an interesting idea, I think I know why it will not, and should not be done.

I don't know an awful lot about the vorbis compression algorithm, but I do know that it is lossy -- parts get thrown away. This might be some ms after a loud sound, high frequencies -- anything which the ear does not notice. So if we're going to compare sample-by-sample from the ogg, I think almost every sample will be off by a little, because of the nature of the compression. So probably the "missing parts"-flac would be close to the size as a compressed flac of the original.

If you want to be able to scale down the HQ audio on your drive, for devises and stuff like you say, you'd be better of using some other method. Vorbis does have theoretical support from bitrate-scaling, meaning that audio can be scaled down without recompressing. However, this is only theoretical as I understand it, and is not yet implemented. But this is the feature you should be pushing for.

Also, if you want to have a lossless file on your computer, and a smaller one on your devise, why not recompress the file on the fly? With a fast computer, compressing takes only 1/10 the time of the actual song, so this would definitely be a viable solution until bitrate-scaling is fixed for real.

Re:Algorithms?

[pclminion]

So what sort of compression algorithm does FLAC use?

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.

Re:Algorithms?

[Ziviyr]

An interesting idea, Vorbis something then FLAC the deltas and put that in the Ogg.

Being lossless FLAC is going to care about a bunch of little details that OGG won't.

Actually I'm going to bet that the Vorbis noise floor management may hurt when FLAC has to deal with it. But FLAC is designed to expect alot of crap to sneak by its main predictors, and into the rice (coding).

So it beats me. I'd like to see the difference with various instruments.

Re:Algorithms?

[Josh Coalson]

It would be a serious feat to integrate FLAC and OGG. They are totally different systems.

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.

Re:Algorithms?

[Captain Nitpick]

It would be a serious feat to integrate FLAC and OGG. They are totally different systems.

You've confused Ogg, the wrapper format, and Vorbis, the lossy compressed audio format.

Re:Algorithms?

[Josh Coalson]

So what sort of compression algorithm does FLAC use?

• interchannel decorrelation: mid-side coding
• intrachannel decorrelation: FIR linear prediction
• entropy coding: Rice codes with a simple context mechanism

For more info see here

One idea that would be really cool is if they could get acheive lossless compression by noting the differences between the original and the .OGG, and appending that to the .OGG. Then if you can just strip off the added info when you make copies to restricted-space devices. The only question is whether this can be done with a competitive compression ratio.

This has been suggested before, but would require all Vorbis decoders to decode to the exact same result, which is not practical (Vorbis decodes to float samples).

Re:Algorithms?

[JimDabell]

It would be a serious feat to integrate FLAC and OGG. They are totally different systems.

FLAC and Ogg are already integrated. Ogg is simply a container file format, it has nothing to do with audio compression. You are thinking of Vorbis.

See the FAQ.

Re:Algorithms?

[Anonymous Coward]

Couldn't they mandate a particular IEEE rounding mode to get deterministic behavior for a 100% lossless reconstruction? Isn't there an integer codec for vorbis now?

Re:Algorithms?

[Elwood P Dowd]

1) I don't know anything about Ogg Vorbis
2) Isn't there some integer decoder everyone was talking about a while back? I think they could use that to deal with this problem.
3) I think there are other serious barriers of entry. That is, the discrepancies between a vorbis file's output and the original might be more difficult to encode than the audio in the first place, and the resulting filesizes might be bigger than FLAC (Or hell, have no advantage over uncompressed audio in the first place.)
4) I don't know anything about Ogg Vorbis.

Re:Algorithms?

[rabidcow]

So if we're going to compare sample-by-sample from the ogg, I think almost every sample will be off by a little, because of the nature of the compression. So probably the "missing parts"-flac would be close to the size as a compressed flac of the original.

Image you have some 16-bit samples:
20456, -1872, 3347, 10000

Now suppose you use a lossy compression algorithm, and the output of the decoder is:
20453, -1877, 3350, 9998

The difference between the two is:
3, 5, -3, 2

These samples can be encoded in 4 bits. (before lossless compression!) You've got a source now that's 1/4 the size.

I don't know if the final vorbis + lossless stage (flac would probably not be appropriate) would be smaller than flac, but it's an interesting idea.

Re:Algorithms?

[Anonymous Coward]

This has been suggested before, but would require all Vorbis decoders to decode to the exact same result, which is not practical (Vorbis decodes to float samples).

It's entirely possible for multiple implementations to provide the exact same float result, after all it's all done through logical computations. The problem is that people assume that it's not possible, so they're sloppy. If you follow the IEEE spec, you'll have the same result from the same set of operations.

Re:Algorithms?

[Josh Coalson]

Couldn't they mandate a particular IEEE rounding mode to get deterministic behavior for a 100% lossless reconstruction? Isn't there an integer codec for vorbis now?

Sorry, I should have said "libvorbis decodes to float samples" (I believe). But the basic problem remains, that in order to make the FLAC+Vorbis thing work would require standardizing the representation of decoded samples which is not practical and doesn't really have any advantages outside this particular untried idea.

Re:Algorithms?

[Anonymous Coward]

This is a pretty good assumption for audio, since the predicted values tend to be quite close to the real ones.

This still sounds lossy to me... 'quite close' is still not 'exactly right', which means a loss of definition, even if it is very tiny. Of course, I'm no audiophile, and a reasonable bitrate OGG or MP3 sounds almost identical to the CD track for me.

And what's with all these people ripping on you for the ogg/vorbis thing? From the context it was obvious you meant the audio encoding used in an OGG file, and not some container format.

The guy who told you to check the faq was especially obnoxious, as if you had no clue at all...

Re:Algorithms?

[pclminion]

This still sounds lossy to me... 'quite close' is still not 'exactly right', which means a loss of definition, even if it is very tiny.

The predicted value isn't what gets sent. They send the difference between the prediction and the actual. On the decoding side, they make the same prediction, then add the "delta" back in, to recover the original sample. The procedure is entirely lossless.

The high level of compression comes from the fact that the deltas are distributed geometrically (because audio is highly correlated in time). Golomb-Rice codes are the optimal way to encode geometric distributions, so that's what they chose.

Yeah, there are plenty of pedants on /. just waiting to pounce on your slightest mis-wording or mistake...

Re:Algorithms?

[caudron]

I think you are thinking of Vorbis, a subset of the OGG project. OGG itself is a wrapper for media (basically). It is Ogg VORBIS that applies psychoacoustic filters to the music. Therefore, when they say Flac will join Ogg, they mean to say that the Ogg family will now consist of:

Ogg Vorbis (lossy encoding)
Ogg Flac (lossless encoding)
Ogg Speex (voice encoding)
Ogg Theora (video encoding)

-Tom

Re:Algorithms?

[Natalie's Hot Grits]

"This has been suggested before, _but would require all Vorbis decoders to decode to the exact same result_, which is not practical (Vorbis decodes to float samples)." [emphasis mine]

Not true.

I don't know if this has been tried before, but the limitation you propose does not exist. This would not require all OGG decoders to produce the same exact result. It would require just all FLAC decoders to produce the same ogg output for the ogg data in the flac file, which is possible.

You'r .ogg personal mp3 player doesn't have to decode the ogg's exactly for a completely unrelated FLAC codec to take advantage of this principle. The only requirement is that all FLAC codecs use the same OGG decoding algorithm.

I believe the problem that is actual has nothing to do with practicality, but that the residual wave form that is produced via the diff between the .ogg output and the .wav output is nothing more than noise, which is not significantly compressable by any means currently known (IOW, the noise would take up as much space as the origional .wav file, because it can't be compressed very well)

If someone found the "trick" to compress this noise (because this noise will definately have a pattern to it, depending on which codec you used to encode the origional .ogg file, and depending on what type of music is being encoded) then this principle would be an awesome breakthrough.

Re:Algorithms?

[Anonymous Coward]

The predicted value isn't what gets sent. They send the difference between the prediction and the actual. On the decoding side, they make the same prediction, then add the "delta" back in, to recover the original sample.

Ahh, I see now... I misread your original post. Thanks for clearing that up :)

I'd like to learn more about how MP3 or OGG compress audio, as most web pages will try and pass off "eliminates frequencies we can't hear" as a full explanation. If that were the case though, MP3's would have much lower CPU requirements, so there must be more involved.

Do you know of a link that might further explain concepts like spectral envelope, MDCT, and subband energies?

Re:Algorithms?

[Pathwalker]

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.

Re:Algorithms?

[JimDabell]

The guy who told you to check the faq was especially obnoxious, as if you had no clue at all...

Obnoxious? He confused two completely different things! Ogg is merely a wrapper format, it has no bearing on the algorithm used to represent the audio. Sorry, but anybody who is qualified to talk about flac vs vorbis simply wouldn't make that mistake.

Is this REALLY a solution?

[moosesocks]

Is lossless really a good idea?

Why can't we develop a codec which is "almost lossless" and works well at higher bitrates? Ogg and MP3 do okay at 320kbps, but the quality increase isn't 3 times a 128kbps mp3.

A good test for encoding quality is to encode new age (enya, enigma) or classical music as they tend to have many subtle, yet distinct instrumental sounds (bells, small symbols, synthesized effects) in the background. Listen to them using a pair of good quality headphones (seinheisser or bose) - you're not listening for artifacts (at high bitrates, you should't find any) - instead listen for the subtle background sounds. THEN, make the decision if lossless really is better. Personally, I prefer 192kbps OGG for my encoding, as it provides reasonably good quality without sucking up my entire drive.

Re:Is this REALLY a solution?

[jankyPhil]

---
Why can't we develop a codec which is "almost lossless" and works well at higher bitrates? Ogg and MP3 do okay at 320kbps, but the quality increase isn't 3 times a 128kbps mp3.
---

That's fine. But lossless compression is important for people that trade and distribute music. Having an *exact* copy is what we want and lossless compression schemes do that for us. In the trading circles that I'm a part of, mp3 and ogg are the product of the devil. :)

Re:Is this REALLY a solution?

[LinuxGeek8]

> Is lossless really a good idea?

Yes, it is.
There are many musicians who want portability. Try encoding some wav to mp3/ogg at home, decoding it in the studio, mix it, encode it again to mp3/ogg and go home to your homestudio.
Then try that 20 times, and see what remains of the soundquality.
Then sure, you can also carry wavfiles if it matters that much to you, but 50% savings can be a lot.

Re:Is this REALLY a solution?

[mindstrm]

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.

Re:Is this REALLY a solution?

[tapin]

Is lossless really a good idea?

Yes. It is.

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.

Re:Is this REALLY a solution?

[kekoap]

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.

Re:Is this REALLY a solution?

[Anonymous Coward]

In the trading circles that I'm a part of, mp3 and ogg are the product of the devil.

How ironic -- I'm sure in industry circles, your trading circles are the product of the devil.

Re:Is this REALLY a solution?

[shepd]

>Listen to them using a pair of good quality headphones (seinheisser or bose)

That's fresh! :-D ROTFLMAO!

Quality + bose in the same sentence.

Please, mod parent as funny!

Re:Is this REALLY a solution?

[Cuthalion]

I don't think that "lossless" sounds three times as good as 128kbps mp3.

Re:Is this REALLY a solution?

[mz001b]

Ogg and MP3 do okay at 320kbps, but the quality increase isn't 3 times a 128kbps mp3.

That's good, since it should only be 2.5 times better.

Re:Is this REALLY a solution?

[SonOfSengaya]

Your apartment is broken into [...] stolen, including that ultra-rare CD [...] No problem, you've still got the FLAC files and can at least burn yourself a virgin, bit-for-bit exact copy [...] of the audio -- your artwork and individually-numbered disc are still gone, sorry.

But that's the point! If I lose a rare CD, no FLAC file could be a compensation. The whole CD including artwork, text and so on is art. the music is the major part but the music is the only thing you can copy! and i think you can get nearly every piece of music at Napster's childs...btw, is it illegal to get mp3s through file-sharing if you lost a CD?

Re:Is this REALLY a solution?

[Sycraft-fu]

Actually one of the most important applications for lossless audio compression is production. The "stuff you can't hear" often because stuff you CAN hear if the sound is processed forther (EQ'd, chorused, etc). It's really not a good idea to use lossey compresison until you are completely down with your stuff. But, saving diskspace is often soemthing that would be nice, multitrack audio can get real big real quick. Hence, a losless ocmpression algortihm is great. Some companies implement one or another in tehir pro software but it would be nice if they were to settle on something like FLAC as a standard so the files would be interoperable.

Re:Is this REALLY a solution?

[Compuser]

I am curious, why would you lose audio quality
with successive reencoding. In theory, mp3
has psychoacoustic model to eliminate frequencies
you can't hear. So once that is done on the first
pass, the successive passes should find nothing
more to eliminate. Where am I wrong?

Re:Is this REALLY a solution?

[Anonymous Coward]

... 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.

Jebus Christ - what are you guys listening to that 192kbps isn't acceptable? Unless you're hunting for submarines on Navy recordings, do you really need *that much* quality?

I'll bet you guys are absolute bastards to watch a movie with:
"OMG - quit breathing so heavy! I'm trying to watch a movie!"

Re:Is this REALLY a solution?

[skryche]

btw, is it illegal to get mp3s through file-sharing if you lost a CD?

Of course - if your copy of Hooky Kooky Lend Me Your Comb gets stolen, and you produce a new copy of it out of the ether, there is now one more copy in existence. You've just lowered the value of every other copy out there by increasing supply. For shame!

Re:Is this REALLY a solution?

[tapin]

But that's the point! If I lose a rare CD, no FLAC file could be a compensation [...] and i think you can get nearly every piece of music at Napster's childs

I agree with your first point -- that losing a rare CD sucks and just having the audio is, of course, not the same.

However: Assuming you wanted the CD not only for the art and packaging but also for the music.... I think you missed the point of the rest of my post when you suggested downloading MP3s to replace your lost disc. Those MP3s are effectively impossible to transfer to a less-compressed (or even differently compressed) format if you want to gain the benefits of the lesser compression. The audio signal's just not there any more. And if you try to change from one psychoacoustical model to a different one, you're essentially ending up with the minimus of the two.

MP3s are great for some purposes. Getting your audio back to a virgin state isn't one of them.

Re:Is this REALLY a solution?

[Natalie's Hot Grits]

There are 3 reasons you are wrong...

1) your suggestion might be technically possible, but impractical. For instance, there is no practical reason to build a codec that has this capability if it will cost more to build than to just use lossless codecs.

2) You still don't have a way to archive the ORIGIONAL SOUND. Would you store your master copy on a record? surely not. The same should be true for lossless v lossy compression/storage.

3) After you decode an mp3, and edit it, then re-encode it, you are no longer re-encoding the origional mp3's output, so you cannot predict its re-encodeability, EVEN IF you did build a codec that could do what you propose.

An example of #3:

have you ever tried to run a .jpg image through photoshop filters? decode it to .psd (basically bitmap image), apply the filter, then re-encode to .jpg, and you will surely see that it won't be anywhere CLOSE to if you had applied the filter to the origional non-jpeg file. The reasoning for this is that the filters do a pixel by pixel filter application, which takes the current pixel, and sometimes surrounding pixels, and alters them depending on what surrounds them. Since you started with a jpg, the surrounding pixels will be somewhat obscured from the origional, and these slight obscurities from the origional could produce drastic changes in the final output.

Re:Is this REALLY a solution?

[Natalie's Hot Grits]

IANAL, but i believe this is incorrect.

If you PURCHASED an album, encode it to mp3 (or download its mp3's off kazaa) and then your origional is stolen, you are not the liable party for copyright infringement, the thief is (that is, he stole a copy of the work you rightfully had, thus breaking the fair use clause, and infringing himself.

If however, you GIVE That CD to your friend, and claim it was stolen, you are nothing more than a pirate.

Re:Is this REALLY a solution?

[Anonymous Coward]

The real question is: are lossy encoders any longer a relevant solution? Data compression was the answer to a problem rooted in a world of 56k modems and 400 meg drives. With the exponentially increasing capacity of both, it's no longer relevant. Very soon it will no longer be necessary to accept less than perfect fidelity to the source, which is the ultimate goal on any media storage system.

Re:Is this REALLY a solution?

[Compuser]

Ok this is getting off-topic.

0) Your sig is offensive.
1) What suggestion?
2) My question had nothing to do with archiving anything
3) If you decode an mp3 and then reencode it would that reduce quality of sound compared with first mp3? Or do you get the same mp3 back bit for bit? That was my question. I understand that if you resample the decoded mp3 or do anything to it, or use insufficient number of bits to store intermediate calculations etc, then yes, I can see how you would get worse sound with every reencoding. But my question is this: if you take an mp3, decode it (with overkill precision), then reencode that back to mp3, do you get the same mp3 back? And are there decoders/encoders where bit length for intermediate calculations can be an arbitrary user-specified number?

Re:Is this REALLY a solution?

[ctar]

In addition to etree, check out furthurnet which is basically the P2P version of etree. Etree is a list where people advertise their (non-professional) FTP servers in order to share live music recordings. (Only legal, band sanctioned live recordings). Furthurnet is an extremely well done java based P2P client exclusively for sharing these legal, live recordings. Etree has high standards for audio quality, and supports SHN and FLAC. Furthurnet supports SHN, FLAC, and MP3.

Re:Is this REALLY a solution?

[Anonymous Coward]

MPEG rounds off signal frequencies and strenghts, and the difference between the stored and actual values ("quantization error") is sometimes perceptible as a signal, changing the output of the second pass (and thus the input to the third...)

Re:sweet

[joe_bruin]

well, my phatbox already plays both flac and ogg (in my car). if they're merging, does this mean i'm losing a media format?

ADPCM is lossy.

[eddy]

ADPCM is lossy, so I'm not sure what you're trying to get at...

I can assure you that FLAC and codecs specifically modelled around sound compression will -- in general -- outdo something general like lz77+huffman.

Agreed

[Anonymous Coward]

... the point is that FLAC is OSS ...

When I first read this headline I was wondering how this could be better then zip / rar / bz2 / etc. Then I remembered that you still need a WAV file (or whatever) to compress first. WAV isn't fully OSS, but FLAC *is*. So this is a good idea: a fully OSS sound format for lossless audio.

Re:Agreed

[Inf0phreak]

WAV is as free as anything. It is nothing but raw Pulse Code Modulation data with a special header with information about the samplerate and bit depth, and that's it. PCM has been around since 1929, IIRC.

Re:Agreed

[Anonymous Coward]

WAV is a container format, like OGG or AVI or the various MPEG profiles. A WAV file can contain the output of a proprietary codec like Truespeech, though simple PCM is more common.

Re:Agreed

[elvum]

PCM is the most common encoding used in WAV files, but the format allows for a large number of other, generally compressed, options. The "special header" you mention is also (or can be) quite a bit more complicated than you make out... :-)

Re:sweet

[mmol_6453]

Xiph is just a host for the projects, akin to SourceForge. You can have three different competing Gnutella clients on SF, but they're independent of each other.

I don't know if Xiph provides anything more than www and IRC, though.

Re:Oh, boy, yet another codec....

[Anonym0us Cow Herd]

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.

uh...

[honold]

the audiotron is supported

Re:uh...

[Zathrus]

And, lookee... I even said that I know Samba can do transcoding, but it requires more CPU power than my server has.

The AT cannot play FLAC files natively.

Software

[Malc]

This is great... but how am I going to encode/decode this stuff without using something with a worse UI than Winamp or WMP? Infact, are there any plugins for these yet?

Re:Software

[Anonymous Coward]

FLAC has been around a while, most players should have plug-ins already. I doubt you'll see FLAC support on portable digital music players for a long time though (FLAC files are huge compared to lossy files, for one; I'm not sure how CPU and floating point intensive FLAC decoding is though).

Re:Software

[Anonymous Coward]

This is great... but how am I going to...

Keep in mind that you are reading about this on Slashdot, not PC Magazine. The answer to your question is: the way you'll do it, is however you decide to do it .. after you get off your ass and write the tools that you want.

Oh, you want someone else to write the tools instead of you? Ok, that's fine. It really is a perfectly valid policy. But then you need to:

1. Leave Slashdot since you obviously are not a nerd.
2. Ask again in January 2005 when somebody else has gotten around to what you want.

Infact, are there any plugins for these yet?

Very amusing. It became part of the standard today, and you are already looking for software. In answer to your question: Yes, the plugin exists, and it came preloaded with the Microsoft Windows Longhorn preloaded Pentium 6 system that you already have.

Re:Software

[Anonymous Coward]

Easy

$flac music.wav
$flac -d music.flac

Now how hard was that? You don't even have to take your hands away from the keyboard and spend 5 seconds waiting for a gui to load so you can search for the function you want and then click through a directory tree. It's intuitive even. Flac is a verb, *.wav is a noun. "Go home" "Sit there" "flac music.wav" are essentially the same construction. so, if you can type, you can use flac

Standard FLAC, or...

[Snard]

AFLAC!

(somebody shoot that duck, please!)

Re:Standard FLAC, or...

[Anonymous Coward]

APFLAC, Armor Piercing FLAC

Re:Oh, boy, yet another codec....

[Bill Currie]

Actually, while it might sound repetative, unless every note is carefully constructed, it's anything but repetative. Even when sampling a pure sine wave it's very rare for the sample points to repeat due to the sample rate generally not being an exact multiple of the sampled wave. Now throw in some traditional instruments (eg, violin, saxophone, piano...) and humans, and things like the exact timing of notes will fluctate wildly at the sample level let alone the fact that many instruments operate based on filtering white (or more likely pink) noise.

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 ;)

It's a go!

[AnonymousCowheard]

With all the news on Microsoft's "new" TabletPC (old idea), I am quite intrigued that Microsoft doesn't have any innovative technology to bundle with their TabletPC; Xiph.org has it! The Opensource "revolution" is crumbling many barriers, including the proprietary ones put up just as a "distraction" (yes, inter-operability with Microsoft's proprietary software is a distraction from good programmers to design and implement better software and standards).

Come to think of it, Microsoft has nothing innovative in the audio and video world. Their AVI format, its many subspecies (wsf, wmf, wma, etc), and the general proliferation thereof are a justified (and quite notable) example of how media standards is not as crucial element in a company's survival. Bill Gates (yes his statment still stands as being verry impressive and of his accurate observation) generally stated that Microsoft's goal is to extend itself to its competitors by ussurping them to use Microsoft software. I just saw a black cat, the same one, walk by twice. XIPH has technology that Microsoft wants; loss-less audio. We know S3's S3TC is a loss-less standard of computer graphics and it is the only standing technology that is keep the DRI project from being able to objectionably compete as an opensource platform. So now, where does Microsoft think its going today? Microsoft has no software forcing anyone to use it now; the better of the software is opensourced and freely available.

In the immortal words of Nelson... "Hah ha!"

Re:It's a go!

[Inf0phreak]

From what I gather from the forums on HA, Windows Media Audio 9 is not particularly good, which doesn't come as a huge surprise to me, as they seem to have more people working there who are (relatively) good at coding, but not as good at understanding psy-models and the intricasies of psychoacoustic encoding.

Windows Media Video 9 looks pretty good from what I've seen of it, but well... firstly it's from MS, and secondly it's still from MS. The quality is pretty much on par with (if not better than) MPEG-4, but snowball's chance in hell that it will ever be playable (legally) on anything but Windows.

Re:It's a go!

[Keith Russell]

XIPH has technology that Microsoft wants; loss-less audio.

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.

Please - no r3mix.net links

[Inf0phreak]

Everyone on Hydrogen Audio disagrees with you. Do NOT link to r3mix.net - that site is notorious for its blatantly false information and crappy comparisons. Read the MP3 forums at Hydrogen Audio and becomre more enlightened.

Re:Please - no r3mix.net links

[shepd]

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.

Re:Please - no r3mix.net links

[Anonymous Coward]

There is no forum vs forum flamewar, simply because r3mix-forum has been practically dead for over 6 months.

People moved to HydrogenAudio after it became clear that all knowledgeable people left r3mix and r3mix admin decided to quit.

There's enough proof that many things which is said at r3mix site is false if you look for it, but not the least because it hasn't been updated for over a year.

R3mix is also responsible of mass spreading false impressions of how psychoacoustic codec quality should be measured.

Simply said r3mix-site is obsolete.

Re:Please - no r3mix.net links

[CaseyB]

Everyone on [my favorite site] disagrees with you. Do NOT link to [this other site] - that site is [bad]. Read [my favorite site] and becomre more enlightened.

Remember kids, you're only allowed to have ONE source of information! You must choose a site, and take everything stated there as the word of God!

Re:Please - no r3mix.net links

[nelsonal]

Dang I accidentally picked /. before I realized you only get one, and now I think that SOVIET RUSSIA is filled with either Beowulf Clusters or Natalie Portman and hot grits depending on who you ask.

Re:Please - no r3mix.net links

[Anonymous Coward]

Okay, no problems with the fact r3mix.net is dead. But really, is there any disagreement that 256/320 kbits MP3 is distinguishable by normal human ears from the source material (assuming the source is 44.1 kHz, 16-bits stereo)?

Just wondering...

Re:Please - no r3mix.net links

[EllisDees]

Lots of talk but no evidence. Has there been a single double blind test where an 'audiophile' has been able to tell the difference between a 256k mp3 and a cd? (Besides the one case where the guy with damaged hearing could tell the difference because he couldn't hear anything above 8khz)

Re:Please - no r3mix.net links

[Anonymous Coward]

Yes, you don't need to be an 'audiophile' to hear a difference. After all, so called audiophiles wouldn't even touch lossy compression.

Anyways, here's a link for few test samples archives. Many of those samples are problematic even at the highest quality level of lossy encoders and can be ABXed by normal people with headphones.
http://www.hydrogenaudio.org/index.ph p?act=ST&f=16 &t=4601

Lossless compression is a joke

[briancnorton]

High quality music recording is great and all, but what's the point? Unless you are recording in it straight from the source, you are still limited by the frequency range and sampling rate of the delivery media. (i.e. a CD) I seriously challenge ANYBODY, even those with true HI-FI equipment to tell me the difference between a CD and a good quality MP3Pro.

On top of this, you are still limited by the response of the equipment you are playing it on. Maybe this would help a little if you had an optical connection to a good amp, but computer speakers will provide more interference than compression any ol day.

Re:Lossless compression is a joke

[KjetilK]

I'm totally without a clue on this, really, but I can think of one obvious use: You want to back up your music collection but use less space to back it up.

If the CD is lost or destroyed by scratches (many of mine are allready), you still have the original recording that you can compress with lossy compression of the day for your daily use. Conversion between lossy codecs is meaningless, but compressing from a lossless format to a lossy format is OK.

So, if Ogg Vorbis 2.0 is better than 1.0, you can make 2.0 files from your lossless compressed files.

Re:Lossless compression is a joke

[hbean]

A deaf monkey can hear the difference between a lossy (mp3) file and a lossless (SHN or FLAC) file. No matter what the sample rate of whatever your source mp3 will cut it off at 16khz. How do you think it makes its compression? Sure, if your listening on a computer speaker, you can't tell, but most people who care enough to bother downloading a file that is 25x the size are going to have their computer hooked up to a decent system anyhow. Go to any etree.org site, and you'll find any number of sources as to how much mp3 ruins the quality of music. Good quality mp3 (192k and above, but once you go higher, your wasting your time converting to mp3) does sound quite like the original, but the loss is still there. This has been proven by members of the live music community (again, etree.org) many many times.

Check your facts before you make bold claims.

Re:Lossless compression is a joke

[Inf0phreak]

> No matter what the sample rate of whatever your source mp3 will cut it off at 16khz

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).

Re:Lossless compression is a joke

[Anonymous Coward]

If you make (electronic) music yourself, for example, then you'd want to keep your material in a lossless archive, too, no matter how good Vorbis @ -q 10 or whatever else is. Instead of WAV, FLAC has great advantages - it's free, it's compressed and still playable (unlike RAR w/ multimedia compression, etc), and it supports metadata that is actually understood by players that support it. Most people who casually listen to music on their computers or portables (with noisy fans, or in loud environments, like a train), don't need lossless. At least most of the time. Some poor bastards have so trained ears that they could notice lossy audio degration while a nuke blows up nearby. Don't underestimate others hearing capabilities, they might end up proving it to you.

Btw, although I haven't ABX'ed any highest-possible quality mp3PRO files, yet, I am sure that even I with my moderately trained ears can find the encoded song. I'll prove this to myself eventually. mp3PRO annoys the hell out of me at 64kbps, and discovering SBR at higher bitrates should be possible for me, too.

Re:Lossless compression is a joke

[atrus]

There is a different between a lossy encoding of an MP3 and an original CD track. If you play your music through "computer speakers," you won't know the difference. Good quality audio equipment will instantly reveal any difference.

Isn't MP3Pro designed for lower bitrates anyway?

Re:Lossless compression is a joke

[Read Icculus]

Remember yesterday's story about the LOC and the massive sound archive? If you want to preserve recordings in a digital format use something lossless like SHN or FLAC, check the md5's and you have a "perfect" copy of that Kaiser Wilhelm speech. Making an mp3 or even an ogg rip of the same speech would be an act of historical vandalism IMO. Lossless means what it says, nothing is lost, the sound is preserved. Plus with a 50% savings in file size you can store almost twice as much data on the same media. As others have already pointed out you can't just zip, or gzip audio data, the reduction in size is next to nothing. As for the your objections re quality, the people who are going to be using FLAC are audiophiles and folks who will be making a FLAC copy DIRECT from the source. Check out http://etree.org for more info about lossless compression and the people who use it.

Re:Lossless compression is a joke

[Anonymous Coward]

A spectrum analyzer will reveal any difference, but if you're just listening to it, even theoretically perfect equipment will not reveal differences your ears aren't capable of perceiving.

Re:Lossless compression is a joke

[SecretAsianMan]

I seriously challenge ANYBODY, even those with true HI-FI equipment to tell me the difference between a CD and a good quality MP3Pro.

Easy. Try archiving old data cassette tapes, like those used with Commode Doors, Trash 80s, etc. This came up a while back on the ClassicCmp mailing list. The idea was to record the actual audio onto digital media that could then be played back into the computers' tape inputs. Sure, it may not be the most efficient way of getting data onto a machine, but classic computer enthusiasts often have rather unorthodox values :-). IIRC there was a general consensus (not scientific evidence) that using current lossy compression algorithms resulted in failure of the classic computer to recognize the audio as data.

Re:Lossless compression is a joke

[Anonymous Coward]

Computer speakers might mask artifacts, but they're at the very bottom of the audio food chain. Any decent equipment, once a listener becomes accustomed to its colorations, will be sufficent to expose the effects of lossy compression. Rather ask, with geometric increases in bandwidth speed and storage capacity, what's the point of lossy compression?

Re:Lossless compression is a joke

[Ancipital]

The point can be summed up for me personally with the phrase "generational bounce". It's not rocket science- every time I encode something it throws a little bit away.

Then I take the result and decode it elsewhere and re-encode it, and guess what, it throws some more away.

Once you've shuttled back and forth a few times with your audio, if you're using lossy compression, the signal sounds like (and this is a technical term) a big pile of arse.

It's all very well to point at anything and go "what's the point?" before thinking about it at all- this is why we love slashdot. I could just as well glare at a carpet tile and decry it with the same mantra- it will seem equally valid an observation to me since I haven't broken into a mental trot.

However, it's nice to see that your comment got modded up, who needs a decent SNR? :)

Re:Lossless compression is a joke

[briancnorton]

"No matter what the sample rate of whatever your source mp3 will cut it off at 16khz"

Wow, I had better go erase all of my 44Khz MP3s then...

Re:Lossless compression is a joke

[briancnorton]

Another thought for you wannabe audiophiles. ALL digital music is by it's very nature a lossy format. When we convert from analog to digital, we decide which parts of the music we dont need. The CD consortium decided that we only need frequencies from 20(?) - 20,000 Hz, and 44khz sample rate. Real noise dosent have a sample rate, it's a convenient method we use to deal with audio to retain the information we need. The same goes for compression.

Sie of FLAC files?

[Delirium Tremens]

Just curious. How many gigs did you need to store your 325 music CDs in FLAC files?
(I mean 'gigs' as in Gigabytes, not the head-banging kind ;)
I am actually more than curious, I am very interested to know. I have a 500+ CD collection that I have never ripped. I think it's time to begin backup-ing everything digitally, but I can't decide between mp3 and ogg (and I don't want to rip more than once either). So FLAC looks like the right thing for me. Just wondering about the size of files.

Re:Sie of FLAC files?

[Garion911]

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..

Re:Sie of FLAC files?

[Anonymous Coward]

Do the math... 50% compression. Typical music CD is 40mins (of 80mins capacity). Say it's 50mins though, for argument's sake. So 50/80*700MB = 437 megs raw. 50% of that would be 220 megs per Audio CD. So your 500 CDs might take 110 megs to store with FLAC. These are really ballpark numbers. As some have pointed out, actual FLAC compression levels could be 30%-70%. But it seems that with luck on your side, your entire 500 CD collection could fit on one 120GB hard disk. With no loss of data. I'm impressed.

Re:Sie of FLAC files?

[peculiarmethod]

'So your 500 CDs might take 110 megs '

i think he means gigs.

or else.. WOW

lol

pm

Re:Sie of FLAC files?

[SnAzBaZ]

Assuming 50% compression ratio, and say the average CD has 600MB of audio on.
That's 325 * 0.5 * 600 = 81250MB for 325 CD's.
Or 500 * 0.5 * 600 = 15000MB for 500.
A 200GB drive will probably cost you $300 or so, so that's $0.6 to backup per CD, with room for plenty extra.

Re:Sie of FLAC files?

[nelsonal]

You might look into AAC, its a little harder to find good free encoders and decoders, PsyTel's is out there but not exactly easy to find, they seem to me to sound better for a given file size. Quicktime Pro supports it as well, they just call it mp4. I ripped mine at a VBR that averages about 160 kbps, and its rare that I notice a difference between it and the CD in an AB test.

Re:Sie of FLAC files?

[machinegestalt]

I would highly suggest using mp3 for maximum portability. One thing about mp3 compression which has always impressed me is that it sounds fairly good at low bitrates and can sound flawless at very high bitrates. Many codecs sound significantly better than mp3 at low bitrates, but most of them still produce artifacts at the highest possible bitrates simple because of the aggressive assumptions they make in order to be able to achieve those low bit rates. The margin of error on a mp3 file encoded with a good encoder at 256kbps is much smaller than all but the best sound systems are capable of distinguishing.

I highly reccomend ripping with cdparanoia and lame, using the --r3mix settings for maximum quality. The --r3mix setting produces mp3 files which average 150-190kbps, using 112 or 128 kbps in the simplest sections and using up to 320kbps in the most complex sections. If you try lame with the --r3mix option I believe you will find that it produces files which are at least equivalent in quality at a given file size to ogg vorbis, and lame NEVER seems to introduce any artifacts, which is something I can't yet say for ogg vorbis.

Re:Sie of FLAC files?

[Deagol]

Well, I don't know the exact GB count. However, they took 165 650MB CD-Rs to back up. That was using a home-brew "optimal" pack using entire albums (I didn't want to fish out 12 CDs to rebuild an entire album). I probably could have shaved off a half-dozen CD-Rs by packing them using individual songs.

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.

Re:Sie of FLAC files?

[Anonymous Coward]

The point of flac is that it is lossless. if you just want something to sound good mp3 or ogg is great. with flac, people can trade bootlegs and other legal recording forever without degredation. every time someone converts from one lossy format to another, well, something is lost. with flac or shn this doesn't happen.

Re:Sie of FLAC files?

[Anonymous Coward]

A 200GB drive will probably cost you $300 or so, so that's $0.6 to backup per CD, with room for plenty extra.

What happens if that drive dies? Yes, you still have the original CDs, but do you really want to re-rip them? Perhaps RAID-1 (mirroring) would be a good idea? Just a thought.

Re:Sie of FLAC files?

[Anonymous Coward]

...and sometimes CD's are longer/shorter. Some CD's are under twenty minutes, some are over an hour.

-someone else.

Re:Sie of FLAC files?

[Penguinoflight]

Cool thought, but your Algothrithm needs a little work. First, most audio cds contain less than 74 minutes of audio. I'll come up with a random number here to take a guess... 50 minutes. Given that 50 is 6756768E-6 of 74, we find that 43918919E-5 is the raw size of these cd images on random average, and the Flac compression rate: 5E-1 of that would be: 21959459E-5 MB. That puts the total size at 71368243E-3 MB or 71368.243E-4 GB

As you can clearly see, it's much simpler to do this whole documentation using scientific notation, and it's gotta be with the capital E.

Re:Sie of FLAC files?

[Anonymous Coward]

not quite...
cd audio is:
44100 samp/s * 16 depth = 705600 b/s * 2 channel = 1411200 b/s

1411200 b/s * 1B/8b * 1MB/(2^20)B * 60s/m * 74m = 746.933MB != 650MB!

you've actually tried this?

[Anonymous Coward]

decoding flac requires next to nothing in terms of cpu

Compression

[phorm]

To add this this...using an extremely simplified example but:

ABABABABCDCDCDCDGHGHGH (22 chars)
4AB4CD4GH (9 chars)

The second line is a different representation of the first, but the same data can be extrapolated. Compression works in a similar fashion, finding patterns and reducing them.
You can get the first sample from the second, and have the same data. Visibly, data is less, but there is no real loss, only a change in representation that gives a smaller filesize

How does it work?

[vondo]

Can someone give a layman's description of how this compression algorithm manages to compress audio so effectively?

I pretty much know how lossy compressions work and how gzip/zip/etc work, but what does this do (that must be specific to audio) that zip doesn't?

Re:How does it work?

[Anonymous Coward]

"Help, I'm too stupid to do a Google search."

Re:How does it work?

[Anonymous Coward]

I wrote a lossless compression scheme a few years ago that got about 50-60% compression by taking the 2nd derivative of the original waveform and Huffman encoding the answer. It was for my patch editor "Everest" with ran on the fabled Kurzweil MA-1 synth chip.

Re:Oh, boy, yet another codec....

[mindstrm]

I doubt it. There is repitition to YOU, but digitally, it's different. THis isn't about "no detectable loss in the waveform".. it's about perfect reproduction of a digital stream.

You could compress any data you want with flac, and get the original back out of it... like zip.

This is a way to store an original, full quality recording without using the same space as the original.. NOT a replacement for lossy high compression codecs.

I use FLAC

[Anonymous Coward]

I ripped my CD collection to FLAC on my PC hard drive. It's like having a CD jukebox that remembers my playlists (WinAmp). I emailed the main developer and he wrote me right back -- nice guy. Thank him (or contribute code or $) if you use FLAC.

G

Slashdot is SO slow these days....

[Anonymous Coward]

What the hell is going on? Is this some sort of ploy to discourage trolls or something?

Are subscribed people gonna get far better response times?

Timeout after timeout.

Re:Oh, boy, yet another codec....

[Andy_R]

Just because you don't have a use for it doesn't mean it's useless!

There is a real market for such a codec in the professional audio industry - have you any idea how much space backing up a 48-track studio recording takes, especially now the industry is moving towards 96Khz/24bit recording?

Respected (at least until Apple bought them!) music software giant Emagic will sell you a program called ZAP which make about a 35% space saving and costs about $100, so free software that beats that is definitely good news for some people.

Fast commandline editting?

[Taurine]

Does anyone know if there is any way to edit FLAC files at the commandline? Like tell it to output a region from a starting time to an ending time to another file?

Editting 30-minute audio files on Linux is quite slow going using the GUI programs. The best I've yet found is GLAME, which at least lets me select a region then resize the region to get things right, but it takes an age. It would be much quicker to pinpoint the start and end points by listening in xmms, then use a commandline.

Re:Fast commandline editting?

[Josh Coalson]

Does anyone know if there is any way to edit FLAC files at the commandline? Like tell it to output a region from a starting time to an ending time to another file?

Kind of. The command-line decoder has switches --skip and --until to decode a specific section, which you could pipe back into the encoder again.

It's possible to make a tool like vorbiscut that will split on frame boundaries.

Re:Fast commandline editting?

[Taurine]

Thanks Josh! I was using version 1.0.4 that was the latest when I downloaded it a couple of weeks ago, which didn't have the --until switch. I've got 1.1.0 now, and my flac editting is surely going to be a lot easier :-)

Not a trivial feat...

[pla]

Somehow, with all of the repetition in music, there has GOT to be a way to do better than that.

The problem comes with the word "lossless".

Music does indeed have a *lot* of repetition, at a high level. If you look at an audio waveform, you can see very regular-looking patterns in the data, that change every now and then but can go on for thousands of samples with only slight variation. At a low level, however, music has a *huge* amount of noise (not noise as in clicks and artifacts, mind you, noise as in stronly leptokurtic Gaussian deviations from what the waveform "should" look like), and even extremely regular plosives just destroy any sort of adaptive prediction-based encoding. For reference, "huge" means on the order of 5 to 6 bits out of 16 (even local nonlinear methods give a RMS error of at best 40ish, but getting that low means storing a lot of parameters of the prediction model, RBF centers and weights as an example).

If you want and extremely high level of compression that you can *almost* call lossless, use FLAC (or Shorten, or Monkey's, or whatever) *after* running your sound through a trajectory-based nonlinear noise reduction filter. You'll see the compression go from 50% to 25% or better (for reference, "archive quality" VBR OGG only gets down to 20-25%). But, you can't *truly* call that lossless anymore, because even though you might not consider the "noise" as part of the music, people *can* tell the difference and usually prefer the version with noise (and, as I mentioned, such a filter blunts plosives, which *should* stay in the music, so you'd need to detect those and add them back in to avoid a noticeable degredation of quality).

Trust me, lossless audio compression does *not* count as a "toy" problem, nor one that people have already "solved" optimally (for example, just about every well-understood time series prediction/analysis technique out there depends on a property called "stationarity", which music very strongly lacks... You can still use such methods, but they give suboptimal results in the best case, and exhibit serious instability in the worst cases). For another problem, *almost all* research on time series analysis has focused on out-of-series error and stability. This lets you do things like predict stock values and the weather. It doesn't, however, necessarily give the best *in-series* error, which matters in an application like audio compression, since you already know the entire extent of the data you need to predict (postdict?). In AI, this has a close analogy to the idea of "overfitting" a neural net - if you train a neural net too long, it learns too many subtleties of the training data and loses its generalization power. Except, in audio compression, you don't *care* about the generalization power, you care about it learning as much about the training data as possible.

Re:Not a trivial feat...

[Anonymous Coward]

Not that I don't like FLAC, (I've got over 200G of FLAC files and growing) but I think since lossless compression is such an exactly defined problem someone who is good with genetic algorithms/genetic programs/virtual machines might be able to make an interesting distributed computing project out of trying to *evolve* a more efficient CODEC.

I tried once but apparently I totally suck at genetic programming, and my populations never got anywhere with it.

Actually,

[FirstNoel]

What I think he means is about non-musician types.

I currently have my CD collection ripped/converted to MP3 (r3mix settings. I know, even those aren't the greatest anymore.) There currently is no real justification for me to re-encode all my CD's in FLAC. Maybe someday I will. But for now I'm happy with my CDParanoia/LAME -r3mix/winamp combination. The files are reasonably small, sound quality is close to excellent.

But for Musicians and people who move/remix music a lot, hell FLAC does look like the way to go.

Sean D.

baudline supports FLAC

[Anonymous Coward]

A 3rd party Linux spectrum analysis tool called baudline supports the automatic loading of both FLAC and Ogg Vorbis audio files. You can use it for visualizing the damage a lossless codec does among other things.

Re:baudline supports FLAC

[Anonymous Coward]

> You can use it for visualizing the damage a lossless codec does among other things.

I think you meant "lossy" codec.

Lossless by definition is a perfect duplicate of the orignal file.

So what if I enter random bits?

[gnalle]

How does a standard compression program respond if I make a large file of random bits and try to compress it. Does it reply with an error message or does it simply return a file that is larger than the original?

PS: This post is a user interface question. I understand the entropy stuff :)

Re:So what if I enter random bits?

[Anonymous Coward]

Typically the output will be larger than the input by the size of a header, which marks the contents as having been "compressed" using the memcpy algorithm.

Re:So what if I enter random bits?

[Anonymous Coward]

The usual technique is to have a fallback "uncompressed" compression method. If the program tries all of the compression techniques, and they all result in compressed files that are larger then the original file, then the file is stored in its original uncompressed format.

A zip file of random data will be slightly larger then the original file -- because of the zip header information -- but never massively larger.

Re:sweet

[Josh Coalson]

if they're merging, does this mean i'm losing a media format?

No, native FLAC will live on; teaming with Xiph will mean better integration with Ogg tools in general.

Finally!

[AyeRoxor!]

"FLAC Joins The Xiph Family"

Finally we can get some reasonable supplemental health care. I love those duck commercials!

Re:Oh, boy, yet another codec....

[bfree]

Can we generate a a filter perhaps like the bayenisian filter from the spam work which discards all the music you don't like? Look at compression, ID3 or other format based headers to determine whether or not your radio station is trying to feed you junk music! If you had a multicard radio system which did delay play (a la video recorder) with this sort of a "spam" filter it would be very cool! You could listen to new music (or football or news), browse your radio archive (a wee lcd will do). Could we build properties which would help classify otherwise indeterminate audio? I think we could but I'm not sure. Here's one idea, speach recogintion software could be trained, by as many people as are willing collectively, to recognise and understand radio personalities (including duplicitous advertisers). Now we could even look at extending it out (and perhaps we should) into all media, including video and web content! Each have their headers and content. Each must leave encoding properties which can provide clues, each must have properties of it's raw content which can be examined. I think we are looking at some serious CPU power to do this as I think about it, but perhaps digital radio broadcasting will expedite matters.

etree

[dylelf]

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.

Depends on application

[Anonymous Coward]

Is lossless really a good idea?

It depends. If you have oodles of disk space and it doesn't matter much space it takes up. But if you have a small memory area (or you have size/power constraints) you may be able to put in a microdrive or whatever. There's also bandwdith to worry about.

Lossy allows you to put the audio in a areas where it wouldn't normally go.

Yeah

[pclminion]

Yeah, I got Ogg and Vorbis confused. My bad. What I meant is there is no simple way to integrate FLAC data with Vorbis data. Obviously there should be no difficulty embedding FLAC data in an Ogg stream.

What the original poster was suggesting would be to encode the file losslessly, and then FLAC encode the residual produced by subtracting the encoded waveform from the unencoded one. This is a very cool idea, but it won't work. The residual signal is going to be very noise-like, so it would be resistant to FLAC compression (FLAC uses a "verbatim" mode when it sees noise -- the verbatim mode does no compression at all). It isn't that you couldn't do it, but I very highly doubt you'd gain anything by it.

And encode track info, etc. how?

[Anonymous Coward]

How do you encode the track, artist, genre, etc. information in zip? How do you go from ZIP to MP3 if you have a portable player. With FLAC you can have a high quality backup (with all info) and convert to lossless when you need it.

Right tools for the right job.

Something to think about

[Anonymous Coward]

CD Audio comes in stereo. That means that there are two extremely similar mono streams (Left/Right). Doing a Huff style tree on the difference between the two streams looks to be what FLAC is doing.

Pretty simple, pretty smart, pretty effective.

Monkeys audio seems to be more aggerssive with it's compression. So much so that it breaks streambility and a couple other nifty things (correct me if I am wrong). While either format is fine for archiving audio, I beleive that FLAC is more usuable in that you can build it into DAW's and such (Digital Audio Workstations).

I sincerely hope it works out for them.

FLAC vs. the World

[yerricde]

check it out to see how other compressors are doing (FLAC is not included, though).

If you want to see how FLAC performs vs. Shorten, Monkey's Audio Codec, and other popular lossless waveform codecs, read this page.

Microsoft Windows won't be around forever.

[yerricde]

Windows is likely to disappear from the face of the earth sometime in 2004

MS-DOS lived from 1981 to 2002. It is no longer maintained; instead, a GPL clone is maintained by the community.

The first good version of Microsoft Windows (Windows 3.x) appeared around 1990. I don't see the product surviving past 2020, let alone the 2080's when the copyrights begin to expire.

Ogg is gapless

[yerricde]

Seamless play. Mp3 by its very nature will cause a pop or blip or something if you rip, say two consecutive tracks from a continuous mix into two files, and then encode them.

MP3 and Ogg Vorbis are overlapping-transform codecs, and overlapping-transform codecs need a short period of silence before and after the signal. The MP3 specification doesn't specify what to do with the silence.

It might be possible to get it right if you engineered your whole ripping process around it (rip an extra mp3 frame of overlap on each file and then throw out that frame once you've done the encoding?) but I don't think anyone's done that.

Xiph.org has done something like that. Vorbis always encodes exactly n samples of silence before and after the audio and then discards them on playback, producing a gapless result. FLAC has been gapless from the start, as each block of samples is independently coded. Thus, Ogg audio as we know it is gapless.

Well, I'll be...

[Anonymous Coward]

I went and looked it up, and it turns out "plosive" is a real word. Now we know what "explosives" used to be.

FLAC input for winamp?

[johnny_4_president]

did i read somebody saying there was a flac plugin for winamp? i didn't see it on their site. please to edumacate me. thanks in advance.

Re:FLAC input for winamp?

[Anonymous Coward]

Yup, FLAC comes with both winamp2 and winamp3 plugins.

URL?

[yerricde]

There's enough proof that many things which is said at r3mix site is false if you look for it

Not everybody reading your comment is an expert at forming search engine queries. Please back up your assertions with URLs.

Re:URL?

[Anonymous Coward]

There's plenty of information, but you could start with this:
http://www.hydrogenaudio.org/index.php?act= ST&f=16 &t=3109

Lossless? I think not! (not from original data)

[Anonymous Coward]

Why does it matter if you have a lossless compression in the digital domain? You already tossed tons of the data out the window in the A/D. Thats one of the big reasons to go digital, you can throw away data that you dont think you need. Mp3 does the same as the CD format. CD's say "we only need 20-20Khz and about 16bit dynamics" Thats what the human ear and our hifi's can handle. The mp3/ogg/MD formats do the same, only in a smarter way. Sod CD's, DAT's and all other crap formats! I sample in 48bit/192kHz! Thats what I will need when I get my new ear implants back from the shop!

WRONG

[raejin_hardonne]

Conversion between lossy codecs is meaningless

this is simply NOT TRUE. I convert between lossy formats all the time. I like to listen to 320kbps MP3 at work, but have trouble fitting them on floppies, so I encode them at 64kbps and then when I get to work, I RE-ENCODE them to 320 kbps. It's a brilliant trick, and I'm suprosed more people don't do it. I must say, however, I expected the sound quality of 320 kbps mp3 to be better than it is...

-RAEJIN

Ear != ear

[yerricde]

even theoretically perfect equipment will not reveal differences your ears aren't capable of perceiving.

Your ears are not my ears, and my ears are not CmdrTaco's ears, and CmdrTaco's ears are not Trent Reznor's ears, and Trent Reznor's ears are not Britney Spears's producer's ears, etc. Different ears hear different artifacts. Lossless audio coding, which I define as audio coding where coding noise is smaller than the room's background noise, is the only way to please every ear now known or hereinafter built.

Re:Ear != ear

[Anonymous Coward]

That's a stupid definition of lossless coding. How about this definition: A lossless coding scheme is one which can be reversed to obtain a bit-identical version of the original.

Fractal compression is lossy and patented

[yerricde]

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'..

Generic fractal compression works only with fractals created by hand. It cannot compress a scene captured with a camera.

So Barnsley came up with a special case of fractal compression called the fractal transform. Guess what: It's 1. patented with no available royalty-free license, and 2. not as efficient as JPEG 2000.

Shannon Limit

[benwaggoner]

Actually 2:1 is a pretty typical compression ratio for all kinds of digitized media. Still images, audio, you name it. Video can get a little bit better, because of interframe correlation.

But for any given encoder, there is always at least one source that will result in output at least one bit more than the input.

Any given content will have a Shannon Limit, which is the maximum theoretical compressibility. The more entropy/randomness in the content, the higher the Shannon Limit will be. A completly random series of numbers will have a a Shannon Limit of the size of the file - it's impossible to compress*.

*and yes, it's cheating to know what the random number algorithm is and working back to the seed number. When I say "truly random" it means "truly random."

Re:Shannon Limit

[gfim]

But for any given encoder, there is always at least one source that will result in output at least one bit more than the input.

I have an encoder that violates that - it's called "cp".

Re:Shannon Limit

[benwaggoner]

And cp is an encoder how?

Re:Shannon Limit

[gfim]

It's called the null encoder. The great things about it are its speed, and that it's also the decoder. However, the compression ratio really sucks!!

Re:Oh, boy, yet another codec....

[UrGeek]

>I'm sure everyone here would welcome any successes you have in researching this.
Oh, so no one has the right to criticized the Tower of Babel unless she has invented her own superior language? Forgive me for having an opinion!

>Maybe you're missing the point.
I think not. I never said that FLAC was to replace MP3 or OGG or whatever. You read that into my word. It is just a 50% decrease over WAV is not enough to trouble switching to FLAC and re-encoded all of my WAV files to FLAC. Or adding to mountain of codecs IN MY HOME. I don't care what codecs you use - knock yourself out. Just don't lay your bum trip on me.

I personally prefer lzip!

[Jugalator]

Now tell me what FLAC has that lzip hasn't! I constantly compress my CD rips down to a few MB's. You can too!

Some impressive stuff from the FAQ that made me leave that Monkey-compression-thingy once and for all:

"We're talking about a constant-time algorithm that can reduce a file down to 0% of its original size. What's not to like?"
---
"You will most likely experience a feeling of euphoria or lightheadedness as you watch your free disk space cascade upwards to 100%."
---
Are there any drawbacks?

"Not that we know of. Occasionally, in the pre-1.0 days, someone would compress a file down to 0K and it would be lost for good. But that has been happening less and less frequently, and these days it has been a long time since we received any complaints from the people who reported this originally."
---

I'm especially impressed by their complex PLACeBO and Lessiss-Moore algorithms.

And don't forget to read their Free-Object Oriented License (or simply "FOO"):

Re:I personally prefer lzip!

[MrNemesis]

Lzip is a lossy compression format. From teir website:

"the real difference is that lzip uses a "lossy" compression scheme. Most other file compression utilities use a "lossless" compression scheme, mostly because the lossless algorithms are better understood and simpler mathematically"

So no, lzip ain't as good as FLAC.

Re:I personally prefer lzip!

[Jugalator]

So no, lzip ain't as good as FLAC.

Read in their FAQ and it says that you probably won't notice that data you'll loose since it chooses the most unimportant parts anyway.

Oh, and it's a joke.

Flamebait? THIS is FLAMEBAIT

[Anonymous Coward]

Omigawd, have got some ultra-sentisive moderaters here or what. Just because someone dares to have an opinion that you don't share, you mod her as flamebait?

I think you prissy-butts need an true example of what REAL flamebait is...

You FLAC whores are a bunch of brain-dead motherlovers who vote Republican!

You single-neuron Mormons needs to get a new wife to add to your collection, one with a brain!

You holey-than-WAV pussy-cats are in a terrible need of a good cleansing douches!

How THAT is flamebait.

And for the sake of Richard-[expleative deleted]-Nixon, do NOT mod as funny. Don't make me come over there!

How to popularize this...

[TheGreatGraySkwid]

It's obvious. They just need to set up some licensing with those insurance people, then start running commercials with a talking duck.

Instant overnight marketing sensation!

Only 50% compression? Try harder.

[Animats]

That seems low. A bit of preprocessing before gzip should do better than that. How about this?

Start by converting stereo to A+B and A-B form. This is lossless, but the A-B track often has less variation than the A+B track; anything that's on both channels doesn't affect the A-B track much.

Then convert those two tracks to deltas from the previous sample. This reduces small changes to small numbers, which compress well in later steps. When the source material doesn't have high frequencies, you'll have runs of similar numbers.

Then reorder the bytes so that samples are sequential, not interleaved. That way, runs of similar deltas are sequential.

Then run gzip, which is very good at compressing runs of similar bit sequences.

This is completely reversible. Try it and see how well it compresses. It should do especially well on instrumental classical music.

After all these years, acronym overload

[Woodrose]

Thirty-three years in the industry, working for government, utilities, NASA, Big5 consultancies and small private shops, writing assembler and 6-character-identifier Fortran (among others), I think I've finally achieved Acronym Overload (AO) reading the title to this article.

I am now certain that my profession is entirely populated by aliens.

Re:Oh, boy, yet another codec....

[Anonym0us Cow Herd]

Oh, so no one has the right to criticized the Tower of Babel unless she has invented her own superior language?

I didn't mean any offense. But I perceive your remark as the typical slashdot complain about something, but do nothing. FLAC's lossless compression might be just about as good as it gets.

It is just a 50% decrease over WAV is not enough to trouble switching to FLAC and re-encoded all of my WAV files to FLAC. Or adding to mountain of codecs IN MY HOME. I don't care what codecs you use - knock yourself out. Just don't lay your bum trip on me.

This depends, perhaps on two things: (1) how large your collection is, and (2) how easily you can automate the conversion.

I actually prefer my software (and hardware devices) to have support for as many formats as possible (except WMA), to give me greatest compatibility. (Not having WMA is my choice.) I still might only keep my files encoded in a (very) limited number of formats.

Re:Only 50% compression? Try harder.

[pclminion]

You freak, you just described EXACTLY what FLAC does.

Except that they go even further than your naive scheme, and use a predictor to get even smaller deltas than your scheme (e.g., assume waveform is locally quadratic/cubic/quartic then extrapolate the next sample). A signal can be varying rapidly and yet still be highly predictable. Your simplistic scheme wouldn't handle it.

Then they use Rice-Golomb coding to encode the deltas. This does FAR better than gzip ever could, because it is designed SPECIFICALLY to handle the geometric distribution of the deltas, whereas gzip is a generic dictionary algorithm.

I really doubt you've even tried what you are suggesting. You're on the right track, but the FLAC team beat you to the punch. Sorry.

Wrong.

[Anonymous Coward]

Microsoft Windows Media 9 is an audio format that was created in light of the FLAC. Microsoft spotted FLAC and mimicked it to the point of near legal battle...

Re:Only 50% compression? Try harder.

[slamb]

A bit of preprocessing before gzip should do better than that. How about this? [...] This is completely reversible. Try it and see how well it compresses.

Umm, you try it. Presumably they've spent a lot of time on designing a format. You should take a little bit of effort before claiming you can do much better, especially since verifying the compression of such a simple format should be easy. Making the claim without even taking that much effort is insulting.

Besides, FLAC has important features your format does not. In particular, FLAC is seekable. As anyone who has tried to quickly extract a single file from a large .tar.gz knows, gzip is not.

better option

[Anonymous Coward]

try zip

Is this any better than...

[Anonymous Coward]

zip?

the point is

[asv108]

So the point isn't that FLAC is new... the point is that FLAC is OSS, and has joined forces with an organization backing such efforts. The SHN codec is not OSS

Most people don't use OSS because it is open, they use it because it is better. The problem with FLAC is that shorten is established as the standard and there are shorten encoders/decoders available at no cost. The only way FLAC is going to be able to thrive is if it does something better. I was seriously considering moving my 500 GB SHN collection to FLAC, but after doing a few test encodes, I concluded that it wasn't worth the hassle. If FLAC were to give me 75% compression ratio that would free up 125 GB for me and would definitely be worth the hassle. But as it stands now, I'm not going to spend a few days converting my SHN collection just for the sake of it using an open file format and this is coming from someone who uses OSS for just about everything (except Photoshop and Sound Forge) .

Re:Oh, boy, yet another codec....

[gnoshi]

Quick point of note: FLAC has been around for a couple of years - it is far from new.

Re:finally, bzip2 compression

[Anonymous Coward]

bzip2 can compress about 30% of .wav files in my tests with 10 classical CD.

Open source lossless auido compression? Been Done!

[wwwgregcom]

And by GNU no matter!

Its called gzip. Try it yourself and see the results!

gzip -c9 audiofile.wav > audiofile.gz

Re:"rebel alliance"?

[Ricky M. Waite]

Microsoft is not the "reigning superpower" in lossless audio codecs; what the fuck are you smoking? In fact, Microsoft is not the "reigning superpower" in ANY widely distributed audio format, lossless or not. Stop the anti-Microsoft rhetoric, please.

Thanks

[Anonymous Coward]

Thanks. Bookmarked. Now we can put --r3mix to rest in favor of --alt-preset standard -Y

Lossless != lossless

[yerricde]

A lossless coding scheme is one which can be reversed to obtain a bit-identical version of the original.

The definition of "lossless" you refer to is a valid definition of "reversible coding of digital signals", and this is what is generally meant by "lossless" in digital audio coding.

However, the "original" audio signal is not bits. The "original" is vibrations in air, which become bits through the recording process. A signal recorded with 4 bits per sample (such as the sampled recordings used by some video game consoles' sound chips) can be represented with few bits and often coded reversibly. But it'll still sound like crap.

That's why I define "lossless" in an end-to-end fashion, implying that 1. the recorded signal is represented with sufficient SNR to put its noise floor below the quietest detectable sound across the entire frequency spectrum of interest, and 2. the recorded signal is reversibly encoded.

not much better than the rest

[blueworm]

I believe FLAC uses rice coding too??? Anyhow, all lossless compressors I've seen never manage to get to 50% with most files.. it's usually more like 60-70%

WHYLO?

[Keith Russell]

Who cares who came first? He said Microsoft didn't have a lossless codec, and I corrected him. Please tell me English is a second language for you. And what "near legal battle"?

Obvious Troll: Keith Russel

[Anonymous Coward]

Keith, you are obviously trolling for dollars today, but you have merits I recognize. From the history of Microsoft, I present:

Microsoft has innovated: NOTHING.

Microsoft has developed originaly in-house products: 0.

Microsoft has purchased other business models, patents, and software: ALL

Microsoft is communism: everyone is forced to use their products and everyone monopolizes the resources so only support is available to Microsoft products and out of shear anti-competitive status other software companies are slandered away from the market by Microsoft-inspired retailers that perpetuate slander.

If I told someone else that your software is bad, you would be angry. The difference between everyone else and you is they are stuck on the Microsoft platform and all these uncorrected Microsoft flaws are manifesting themselves and whoever tries to disclose the flaws or speculate on the severity of the flaw are immediatly prosecuted as being a (pseudo) Computer Hacker or Cyber Terrorist or criticized on your merits as a "rogue" individual hell-bent to destroy some oblivious aspect of the free market. Did I make sense? Microsoft...there is nothing more to be said because nothing *originated* from them to begin with; they bought their technology and extended it to the point of no return to security and stability. They're just a bad pun that keeps getting construed more than the ol' Benjamin Franklin quote, "give up freedom for little security...deserve no freedom/security, etc".

Another Microsoft Worm appears. I always wonder how someone gets the NDA clearance to view Microsoft's code because that is the only way these worm-authors know how to target Microsoft's internal flaws 99% of the time. I wouldn've be surprised if Norton is in-bed with Microsoft. Norton makes a hefty ammount of money providing utilies that secure a Microsoft Operating system from design flaws: anti-virus, filesystem problems, windows registry errors, system diagnostics and recovery.

printf("And they want to replace this!\n");
printf("Aieeeeee!\n");

Re:Only 50% compression? Try harder.

[Daniel Phillips]

That seems low.

That's because you haven't thought about it very hard. Consider that each bit you strip away from a sample takes away half the dynamic range. So if you strip away 8 bits from a 16 bit sample, you are left with 1/256th of the bandwidth of the original signal, and you still want to encode in that miniscule space every little nuance of the original signal. Got more respect now?

ADPCM is cool.

[Tord]

ADPCM encoding is actually quite cool, it has some advantages compared to other compression algorithms, but in the end I don't think there is so much use for it.

I once wrote a very simple ADPCM encoder which we used for the soundtrack in a computer game (Ignition, released in around '96 for PC). The advantages of that one was:

1. Compressed 16 bit audio to 4 bits, giving a compression ratio of 4:1.

2. Extrememely fast decompression, decompressing and playing actually took less CPU resources than just playing the original WAV file. This because I just needed to send each sample through two very small look-up tables (less than 1kb in total) which therefore were cached and uncached memory reads from main memory was decreased by a ratio of 4:1.

3. Very fast compression, almost as fast as decompression.

4. Very simple algorithms. Both compression and decompression algorithms were written from scratch and tweaked in less than two days, including WAV-conversion tool.

5. Good sound quality. Sure, the difference could easily be spotted by a trained ear by direct comparison with the original using good sound equipment, but there were no specific artifacts, just a feeling of a lowpass filter having been applied (which basically is what happens with ADPCM compression, it smoothes out the soundwaves a bit).

However, there is still no compelling argument for using ADPCM today except for very specific needs. Compression/decompression speed is with todays fast processors secondary to the quality/size ratio. 256 kbit/sec mp3 or Vorbis sounds definitely better than 4 bit/sample ADPCM and is notably smaller.

Re:Open source lossless auido compression? Been Do

[Anonymous Coward]

ln -s bzip2 gzip

No, it's a stop!

[Anonymous Coward]

...which only works under XP, not any earlier version of Windows.

D'oh!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Not FLAC and OGG

[Jadecristal]

Ogg is the *container*, and Vorbis is the lossy audio codec designed as a free replacement for MPEG 1 Audio Layer 3 (MP3).

Ogg, the container, is also useful for other formats, as it's more of a "packet-izing" thing than a format.

I think.