HydrogenAudio

(http://www.dogsonacid.com/images/smilies/icon5.gif)

Please also state your reason why...

I use FLAC.

Simply because my old DAP (Rio Karma) supported it. Now I've got a iPod w/ Rockbox, but simply can't be bothered to convert them for the minimal space I'd save.

I use WavPack because of the smaller file size and the better encoder options "-h -m -w -d "CUESHEET=@*.cue"". Also I find it to be more actively developed.

WavPack because of good encoding/decoding speed and at the same time better compression.

Wavpack: higher compression

FLAC, because my iAudio supports it. No other reason than that.

I used FLAC for quite a while, but I recently switched to WavPack (for the same reasons listed above).

WavPack - because of better compression and hybrid mode.

WavPack - because of better compression and hybrid mode.

My voice is for WavPack, but I have converted more than 1000 files into flac the last days (mostly to remove hybrid encodings I had and that don't arrange me anymore).

Garf's flac 1.1.2.1 -8 often gives me a better compression ratio than WavPack -fx5. The difference is rarely important, excepted some case:
- some mono album (problem corrected with 4.4 which unfortunately break older decoder)
- some harpsichord albums
- few other ones.

This flac setting (-8) is also faster on the encoding side than (-fx5) [I recall that I never found one file that was smaller with -fx6], and offers a identical decoding speed on my Duron 800 (x60) but a significantly higher one on my Mobile Athlon (x120 vs x150).
I don't use the normal and the high profile of WavPack, because decoding speed is clearly lower (especially with -high).

But what I always hated with flac was the tagging format, which isn't really compatible with massive and constant tagging. With foobar2000 0.9, the problem is gone (at last), and tagging is now as fast as WavPack and all APEv2 based file formats. Nevertheless, the problem is still present with flac/cue files, and adding a new field takes a good minute with this format 

I'm still a WavPack user, because I still have 1500 hours of music in WavPack format. But EAC is currently set to use flac 1.1.2.1... Both formats are great, but I prefer WavPack over FLAC for several reasons.

I've used Wavpack lossy, but I've just acquired a new 120gb harddrive so nothing inhibits me from going lossless 

FLAC because it is universally accepted and compatible with shntool and Toast. If they ever do get around to incorporating support in Audacity, my cup will runneth over.

I use both, for different reasons.

I use WavPack to rip to image w/ embedded cue, so if/when EAC adds test&copy for images, I will probably completely change over.

FLAC because of wide Linux support and embedded cuesheet metadata block (for my backups I prefer one .flac for one CD).

Between FLAC and WavPack I use FLAC for it's cross-platform compatibility.

However, newer rips I encode using OptimFrog --mode extranew.

So, there.

Other -->> Apple Lossless

Simply because its the only lossless format which is supported by the software and hardware I use. Like iTunes, AirTunes and iPod's.

This is spooky. 

I was going to start a new "Your lossless codec of choice" poll this morning.  I was half way through setting it up, and ran out of time.

The last one started August 2004 I believe.  I think it's about time for a new one.


WavPack BTW.

Edit: Sorry, a reason:  better compression (my first choice was Monkey's Audio for the same reason); ease of use; the @ thing.

Wavpack -- I like the name better.

Wavpack for the hybrid feature. I don't use lossless for listening, but for transcoding or if I need to burn an audio disc.

WavPack because it's faster.

FLAC - more support, faster decoding.

Wavpack: fast decoding, good compression, great support within fb2k and Rockbox, many useful features.
But honestly, if it wasn't for the last two points, I'd use YALAC (or however it will be called).

Wavpack. Partially because Bryant is a hell of a great guy.

I use WavPack.  I like the extra compression, although small.  Also I make music it is normall 32-bit, which FLAC does not seem to support.  The APEv2 tags are more convenient for me.  Editing the vorbis comments on FLAC can be very slow sometimes.  I still have a lot of FLAC's around, but I prefer wavpack.  Encoding/decoding is only a very small amount slower, and if optimizations like MMX are included in the future that may change as well.  If I recall the license on the source is more open than FLAC as well.

EDIT:  Thought I'd add I also love the -m function for storing MD5's in wavpack files.  -hxm all the way.  Especially now with the MMX optimized encoder.  Can't wait to see what the future bring so for WavPack.  Since both FLAC and WavPack are supported in everything I need them to be I still have both.  In the end if one dies and the other doesn't I won't have as many files to convert at least.

shouldn't you had inclided monkey, alac, yalac, wma lossless as choices?

Wavpack, better compression

shouldn't you had inclided monkey, alac, yalac, wma lossless as choices?

In a poll called "Do you use FLAC or WAVPACK?"?

However, I agree: a full "Lossless codec of choice: 2006" poll is well overdue.

This one is gripping though, and only goes to confirm my expectations: WavPack is getting more popular every day.  New members are seeing the benefits of the format, and even existing FLAC users are converting.

Kudos to David.

FLAC - partially because my copy of EAC is already set up for it; partially because it works well for me; and partially 'cause I just don't feel the need to try anything different right now.

WavPack

I like the compression ratio, the decompression speed and it's (slowly) increasing hard- and software support.
An other trait that I like is the -m switch. (-->Paranoid about corrupted audio files<--)
And it was my first (but not only) lossless encoder I've used and I'm still happy with it.

FLAC -8 because of the fast decoding speed and native tags. I don't care about 2-4% less compression.

FLAC because:
1. it decodes faster.. (dont know the difference of my battery live of my iRiver with Rockbox)
2. it has better support..
3. the embedded cuesheet metadata block (one cd -> one flac, but Rockbox doesn't support that  )
4. it is streamable (wavpack isn't)

WavPack for a few reasons.

• Faster compression speed with -h while being smaller than FLAC -8.
• Not that much slower than FLAC to decode on my 2GHz CPU (definitely not enough for me to really notice).
• Very well supported with Rockbox should I choose to use it on my H140.

FLAC is a fine format but WavPack has better suited my needs now since 4.1

Flac, mostly for the better Linux support.

Then again, I haven't even tried Wavpack out yet...

I saw an alternative at Ikea called FLATPAC

WavPack, because of better size to decompression speed ratio and faster tagging. What actually pushed me to do the switch from Monkey's Audio was this extensive CLI for advanced use with EAC.

wavpack, largely because of the ability to embed cuesheets in my cd images.  another reason i like it so much is its the flexibility.  as my sig shows, i use rather specific and slightly extreme switches, because encoding time is irrevelent to me, but decoding speed is very important.  using the "-fx" switches, i can get pretty good compression w/ excellent decoding speed.

I switched from Monkey's and FLAC to Wavpack.
Switched for better compression (from FLAC), error robustness and featurefull encoder. It seems to be more actively deleveloped also, though FLAC is more widespread.

can someone fill me in about this supposed "slowness" of FLAC tags?  guruboolez keep repeating it, but the reference encoder puts in 4k of padding by default, and you can change that in the unlikely event you really need more.  with proper padding all metadata edits are instantaneous.

Josh

I think he needs (but doesn't want) 32kb~64kb (sic) of padding.

http://www.hydrogenaudio.org/forums/index....4580&hl=padding (http://www.hydrogenaudio.org/forums/index.php?showtopic=24580&hl=padding)

FLAC because:

4. it is streamable (wavpack isn't)

The official site and wiki say that it is streamable, so where are you getting this from ?

No implementations, maybe?

I use both.

Wavpack for the handful of 192k/24bit DVD-A rips I have.
FLAC for the rest.

I have no issues with any of the programs. My mass encoding/tagging script is optimised for FLAC and I am too lazy to change it to Wavpack (and there really is no point).

I started Lossless with Flac some years ago,
went over to Wavpack,
and switched back to Flac some months ago.

Of course, without transcoding from the one format to the other, just keeping, what I had stored on DVD+R.

Both formats are very well !
So, the decision to use wavpack, or flac, well, both are so great,
yes, and especially bryant is a nice guy and jcoalson has been politely and always active here in forum also, maybe both seem to be an exception to the usual coders;)

So, why do I encode new rips these days to flac instead of wavpack ?
because hardware support will matter sooner or later.
VW (Volkswagen) will build in soon a car radio with flac support, i assume like Volvo the phatbox(or Keg?) or how it is called.
Volvo.
and all the other Flac devices.
So, as my feeling tells me, it is to expect, that in nearer future, sooner or later, every (cheap) device (which could play lossless) will be able to play Flac.
Unfortunately, this is less likely (to my feeling) for wavpack.
It would be great, if Wavpack would get more devices to be played natively.
Maybe, it is time for wavpack, not to concentrate even more on nice (encoding/decoding) software features (wavpack is already great!), but to get it accepted and built into even more hardware than today.

My encoding settings:

Wavpack:  -x -m
(great compression ratio with same/similar decoding speed as flac)

Flac: -8 -V
(best compression ratio of flac, though not as good as wavpack -x)

I won't use the -h option for wavpack, though the half decoding speed of -h would still be ok for fast PCs, but maybe unsafer to use in possible hardware devices regarding speed/decoding abilities & battery consumption.
And Wavpack -x & flac are very convenient&fast for transcoding to mp3/Lame eg., or if i ever should transcode to any Loslsess format, which might be played in future by hardware devices.

WavPack - speed, warm fuzzy feeling

can someone fill me in about this supposed "slowness" of FLAC tags?  guruboolez keep repeating it, but the reference encoder puts in 4k of padding by default, and you can change that in the unlikely event you really need more.  with proper padding all metadata edits are instantaneous.

Josh

Hi,
the problem I mentionned is maybe a consequence of a bad support of padding in several application. It was the case in the past at least. For example, it's only after I complained about it three years ago that Case introduced padding support in the dedicated diskwriter component of foobar2000:
http://www.hydrogenaudio.org/forums/index....ndpost&p=126256 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=9928&view=findpost&p=126256)
It also seems that foobar2000 improved tag editing inside flac, vorbis and mp3 - which should imply that previous versions where not so good (it has to be confirmed though). I also remember other applications I tested some time ago (was it Tag & Rename, I can't say anymore) which doesn't take advantage at all from existing padded area.
So if I'm not wrong, to be a working solution padding must be supported by tagging editors and it's (or was) not apparently always the case. Such issue doesn't exist with tags located at the end, even with poor tagging software.

I complained for another reason: I was used to add several tagging fields inside lossless encodings. In a not-so-old past, my favorite hobby was to add EAC's extraction log file as a dedicated field. Because .log files are 4...10 kb long the 4kb padding size was by far not enough. I finally leave this bad habit because it causes annoying issue on memory usage (foobar2000 took -database loaded in RAM- 120.000 Kb... and not all files were tagged or present in the library ).

Nonetheless, as I reported (http://www.hydrogenaudio.org/forums/index.php?showtopic=43891) it in fb2k forum 2 days ago, there's a common (I'd say) situation where 4Kb is not enough: it's flac+cue situation in where one single file must endure the charge of information usually splitted in multiple tracks. For example, when I encoded two days ago a mono disc for testing WavPack 4.4, I did first in flac format as single albumfile and by using freedb information only. Here's the result (log by frontah):

FLAC, Vendor: sjeng.org libFLAC 1.1.2.1 20060107
513.583 kbit/s, 16 bit, 44100 Hz, Stereo
Length: 46:12.760

Filesize: 177 975 519 bytes  (169.73 MB)
Uncompressed: 466.29 MB (36.40%)

-------- Tags --------
Vorbis (207 items, size: 11 323 bytes)

Not only the file had to be rewritten just after the encoder finished its job, but if I add a new field to the basic ones, the file has to be written again for a third time because the padding reservoir is already vanished... That's why I suggested to foobar2000 developers to:
- use more than 4Kb padding when a user set the converter to "create a single file with cuesheet"
- add a new padding reservoir when the first one is full

A second situation where tags located at the beginning are possibly boring: adding cover (usually more than 10 kb) inside a file... Once embedded (and files rewritten), there's still no padding anymore and each tags revision implies a new happy moment of rewritting. With large storage capacity of modern HDD and with masstagging software, a simple revision of all files (i.e. convert "NUMBEROFCD to "TOTALDISCS") may took a complete afternoon, with possible corruption (if the app. crashes) but only 15 minutes with APEv2. You see the problem?

So I don't think people have to use tags in an extravagant manner to be annoyed by FLAC tagging system. But with foobar2000 0.9 I admit that my daily tagging experience is much more positive than in the past (excepted for CD image, to be avoided unless stoic patience )


EDIT: I'm using 16384 kb of padding with flac. Could you tell me if there's a limit for padding? I thought I read once 16 or 32 Kb as limit, but I didn't found the information again.

I use wavpack. It is cutting edge technology, great to play with but it really does work practicaly. Amazing software and developer.

I use monkey and have been for the past few years, it was the 1st lossless format i used and just kept on using it.

APE High - I use lossless for archive and listen MPC, and I encode to lossless in batches and write to DVDs - so encoding time  is important, and compression too. Decoding time isn't so important - I'll need this only if I lose my MPC or if I decide to re-encode to different format/settings.

Recent convert to Wavpack.

I was using FLAC for overall performance and cross-platform compatiblilty, but after a few quick tests wavpack seems to perform a *little* better on compression and speed; most significantly wavpack is nicely integrated into Audition 2.0 (my editor of choice and habit) right out of the box. In addition Wavpack is the first lossless codec I've seen that can deal with Audacity's peculiar 32 bit float format without having to run the codec from within Audition (using the -a switch).

I go for Wavpack. It's fast and has better encoding ratio. Flac might get more support on portable devices but I would use lossy instead.

If YALAC really join with Flac, I might consider changing.

Wavpack is better,I think.

EDIT: I'm using 16384 kb of padding with flac. Could you tell me if there's a limit for padding? I thought I read once 16 or 32 Kb as limit, but I didn't found the information again.

the limit is 24MB

I see what you're saying.  there are disadvantages to tags being at the end which is why it's not done that way in FLAC or vorbis.  I agree if you're compressing whole CDs and adding a lot of metadata afterwards you need more padding.  in that case 40k on a 400M .flac is only 0.01% of the file.  but flac cannot detect that case automatically unless you give it a cuesheet during encoding, at which point you don't need as much padding anyway.

I find the emphasis on speed and compression somewhat odd, given the difference between the two seem pretty insignificant.  Looking 5 years ahead, storage prices will be cheap enough to hold all your music in lossless format (in which case, why even have lossy?).  The more important issue to me is a standards setting issue. 

- Will there be devices to support it on your home stereo?
- Is the format supported by a portable player? Car?
- Can you purchase music in that format?

This standards war is already being fought out by Microsoft and Apple, two formidable players.  I just hope that some non-drm technology will be available as well.  But this will happen only if there is a big enough market for the lossless format, whether that be FLAC or WavPack. 

So right now, I believe FLAC is better in each of the departments above, so I use FLAC. 

If it ain't, someone let me know before I finish burning all my CD's to FLAC.

This standards war is already being fought out by Microsoft and Apple, two formidable players.

It doesn't seems obvious to me that lossless audio is the favorite battlefield for Apple and Microsoft  Moreover, both format/compagny are providing lossless encoding tools without any form of DRM. Finally, don't forget MPEG-4 ALS (for interested people, it was apparently updated (http://forum.doom9.org/showthread.php?t=110399)).

I find the emphasis on speed and compression somewhat odd, given the difference between the two seem pretty insignificant.  Looking 5 years ahead, storage prices will be cheap enough to hold all your music in lossless format (in which case, why even have lossy?).  The more important issue to me is a standards setting issue. 

- Will there be devices to support it on your home stereo?
- Is the format supported by a portable player? Car?
- Can you purchase music in that format?

This standards war is already being fought out by Microsoft and Apple, two formidable players.  I just hope that some non-drm technology will be available as well.  But this will happen only if there is a big enough market for the lossless format, whether that be FLAC or WavPack. 

So right now, I believe FLAC is better in each of the departments above, so I use FLAC. 

If it ain't, someone let me know before I finish burning all my CD's to FLAC.

I subscribe fully to your text.
This is the reason, why I changed in my Lossless career from Flac to wavpack to flac again. Wavpack is technically of better overall performance than flac, but flac got recently some major hardware device support by real companies.
But you and me don't need to worry, if you have your music  Losslessly as Wavpack or Flac, you made nothing wrong, in the case, one or the other format might be implemented in your next hardware device, you can transcode easily and quite (more or less) quickly.

Flac because plugins were available at the time for the players/rippers I used under both Windows and Linux. Had grip (linux ripper) had wavepack, I might have gone that way.

That's a qualified "flac because of better cross platform support", I think...

Mark

Wavpack, good speed, better compression, actively developed here at HA.

Can you purchase music in that format?

Another reason I like FLAC is this one - I collect (legal) live bootleg concerts, and a lot of traders use FLAC as a sorta-universal format for distributing these recordings.

WavPack, because I get better compression with a pretty small tradeoff in encoding/decoding speed, even when using the -h option.  Since I use foobar2000 for playback, and don't have a lossless capable HW player, compatibility doesn't really concern me, so I made my decison based on filesizes, and WavPack consistently delivers smaller ones.

Flac. Since my hardwareplayer supports it native. Before i used different compressors cause all i did was playing them in Winamp.
The first time i sorted this i came to Wavpack high cause of its fast and high compression.
Some weeks later i switched to flac cause of my player. Some weeks after i switched from flac to flac!
Ehm.. 1.1.2 to 1.1.2.1 --best
This is so beautiful  with this lossless stuff. When your CPU feels bored just let it reencode without a loss!

Wavpack - compression ratio mainly.  No player that supports Flac so I am either listening to them on PC or sending them to MP3 for my portable.

Is it pretty easy to convert from FLAC to Wavpack or vice versa or do you require to decode back to WAV first? Any programs that automate this process?

A painless switch is always good when you are doing GIGs of data!

I use WavPack.
(Yes I like the red foobar2000 wv icon)

Unfortunately, I'm quite unhappy when I use Linux. There are few options then.
Basically I just dislike XMMS.
Quod Libet is a really nice piece of program but just refuses to play some of my wv files while other just play fine. Me being blind or something?

Is it pretty easy to convert from FLAC to Wavpack or vice versa or do you require to decode back to WAV first? Any programs that automate this process?

You could pipe from one to the other on the command line, e.g.:

FLAC --decode --stdout file.flac | WAVPACK - file.wv

... but by far the easiest way would be foobar (or dbPowerAmp which I don't use), as it will copy over the tags at the same time.  foobar would pipe to the encoder, so no temporary WAVE file required.

Is it pretty easy to convert from FLAC to Wavpack or vice versa or do you require to decode back to WAV first? Any programs that automate this process?

A painless switch is always good when you are doing GIGs of data!

foobar2000 and dBpowerPack are fine for this job (both are also keeping the tags and the latter also keeps RG gain and offer an option to delete the source file after encoding).

... but by far the easiest way would be foobar (or dbPowerAmp which I don't use), as it will copy over the tags at the same time.  foobar would pipe to the encoder, so no temporary WAVE file required.

Foobar only converts tracks though, not an image.  I have not found a way to have it properly convert a whole image with CUE sheet especially if there is a index 0 before track 1.

I still use FLAC -d....

-Robert

I use: WavPack (Normal, -m) via Speek's WavPack Frontend
Reason: Because I want to!

This is the batch file that I use to transcode between album images:

for %%i in (*.wv) do "C:\Program Files\WavPack\wvunpack.exe" "%%i" -d
cls
for %%i in (*.flac) do "C:\Program Files\FLAC\flac.exe" "%%i" -d --delete-input-file
cls
for %%i in (*.ape) do "C:\Program Files\Monkey's Audio\mac.exe" "%%i" "%%i.wav" -d
del "%%i"
cls
for %%i in (*.wav) do "C:\Program Files\WavPack\wavpack.exe" -h -m -w -d "CUESHEET=@*.cue" "%%i"

wavpack, better compression, it is very fast on my machine and it is the one I used first. When I firtst started investigating about the lossless format, one thing i made me decide towards wavpack was that it was the codec with most features. I recognize that FLAc is quite good too.

I love both FLAC and Wavpack. Only reason i am favouring Wavpack for the time being is

- Hybrid mode. With TCPMP's upcoming Wavpack support in MKA, it could be very interesting to store the Hybrid + correction in one MKA, and extract the lossy part for mobile use in a very fast demuxing process then, if necessary

- frame accurate editing. Being a video freak, i hope we will have a video editing tool available one day that will allow us to cut videos with Wavpack audio, to compress them into the end format then.
It would be great for DV video editing, should we be able one day to extract Type 2 DV AVIs into MKV's with Wavpack audio, instead of PCM

Christian
matroska project admin

.WV in -h mode.

Wavpack, with the -x6 command-line, because I like the .wv extension.

I use WavPack.
(Yes I like the red foobar2000 wv icon)

Unfortunately, I'm quite unhappy when I use Linux. There are few options then.
Basically I just dislike XMMS.
Quod Libet is a really nice piece of program but just refuses to play some of my wv files while other just play fine. Me being blind or something?

Quod Libet uses the gstreamer-wavpack plugin and there are some problems with earlier versions (like 0.8) of that. I don't know my way around Linux yet to know how to upgrade, but that's what you need to do (you might need an updated app also, I don't know). The problem was that WavPack "high" mode files crash the plugin. And, files before 4.0 will not work either, in case you have some of those. I have the same problem with Rhythmbox.

Hope this helps... 

Not that my opinion counts or anything, but I use flac. I chose it originally for a few important reasons: While researching different codecs, it appeared that the flac format had been well-thought out right from when it was first conceived. By this I mean that it seemed that the format is the most "general" in terms of future expandability and upgradeability (had the best of these features). Already a few lossless codecs have come and gone, and I think the flac developers designed flac taking into account the shortcomings of those other formats (not that there's anything wrong with any format, but this is a learning process after all, right?).

Secondly, even though it doesn't get as good compression as the others, I decided that nowadays that's not really an issue because storage space is becoming quite cheap. For example, I bought a new Maxtor 200 GB hard drive a few months ago for $85 Canadian at Best Buy. So for me, another 3% savings isn't going to help too much. The trade-off for compression is the decoding speed; I can decode a 400 MB flac file coded with -8 compression in under a minute, and I think that's pretty good. Finally, it has good hardware support, which is a big plus.

My only beef is the metadata; I do wish that the cd-text info could be stored in the cuesheet metadata block instead of having to be in a cuesheet tag.

Edit: Actually I just re-tagged all my flac images to get rid of the cuesheet tag. I kept all the cuesheet metadata blocks, though. What I do now is just drag the cuesheet file (with song titles) into foobar, and it parses that and you get the names. So it's really no problem at all.

And very last, it's good to see that flac is still in development also. Of course it's fun to get on board with a new emerging format and adding your input into the development, but I'm not much of a software guru, so I appreciate having a finished working product that is essentially bug-free (at least I haven't found any), and reliable. I have tried wavpack and I think it's also good. I do think that hybrid-mode is really cool.

Hi,
the problem I mentionned is maybe a consequence of a bad support of padding in several application. It was the case in the past at least. For example, it's only after I complained about it three years ago that Case introduced padding support in the dedicated diskwriter component of foobar2000.

I complained for another reason: I was used to add several tagging fields inside lossless encodings. In a not-so-old past, my favorite hobby was to add EAC's extraction log file as a dedicated field.

Nonetheless, as I reported (http://www.hydrogenaudio.org/forums/index.php?showtopic=43891) it in fb2k forum 2 days ago, there's a common (I'd say) situation where 4Kb is not enough: it's flac+cue situation in where one single file must endure the charge of information usually splitted in multiple tracks.

You know what solution i could offer to your needs, but i also do know that most of you guys are anti-MKA and there are also no good, automated file creation tools available still, so i better shut up here .....

Christian
matroska project admin
http://www.matroska.org (http://www.matroska.org)

I'm using matroska for most of my videos needs  Matroska audio is not as convenient, has few support (not your fault), is not bug free (I'm talking about foobar2000 0.83 plug-in).
I'm sure that what you call "anti-mka" attitude is more trivially a consequence of the lack of tools for creating/using (playback, tagging, hardware support) this container for that purpose.

I thought that Matroska was better suited to A/V needs to begin with, and never considered it strictly for my audio files.  Is this an incorrect assumption?

FLAC because I'm used to it.

Wavpack - better compression and hybrid mode

I mostly use Wavpack, not so much for music archiving per se but for my own loops and samples backups. Wavpack doesn't remove the rather exotic but very useful RIFF subchunks which are created by some audio software(loop tempo, loop pitch etc...)

WavPack for speed, compression and hybrid mode.

Wavpack because of its perfect cue-sheet support and because bryant is such a friendly guy.

past : FLAC for fast decoding.
now : WavPack for better performance (encoding speed, compression).

FLAC.. just because I'm keeping all albums in matroska containers.
Yes, I know that matroska theoretically supports wavpack... but somehow I always get errors when I try mux in wavpack audio.. tried few times and had no time to look deep into that issue.

WavPack. Best efficiency, ie. decoding speed vs size.

As usual, I tried them all. Optim, APE, FLAC, WV etc. I settled on WavPack - best overall speed vs decode speed vs size. I'd normally have said APE but at maximum compress, it decodes like an absolute dog.

This is only for my very favourite albums. For everything else I have, MusePack.

Dhry

Newbie here & a virgin post!

Wavpack rip to image with cuesheet & log embedded.

FLAC. I just havnt given any thought to it... And FLAC seems to be the standard format people distribute lossless in.

So, basically the reason I also use MP3: It's the standard.

Quote from: zepoloo on 2006-04-24 17:41:52

I find the emphasis on speed and compression somewhat odd, given the difference between the two seem pretty insignificant.  Looking 5 years ahead, storage prices will be cheap enough to hold all your music in lossless format (in which case, why even have lossy?).  The more important issue to me is a standards setting issue. 

- Will there be devices to support it on your home stereo?
- Is the format supported by a portable player? Car?
- Can you purchase music in that format?

This standards war is already being fought out by Microsoft and Apple, two formidable players.  I just hope that some non-drm technology will be available as well.  But this will happen only if there is a big enough market for the lossless format, whether that be FLAC or WavPack. 

So right now, I believe FLAC is better in each of the departments above, so I use FLAC. 

If it ain't, someone let me know before I finish burning all my CD's to FLAC.

I subscribe fully to your text.
This is the reason, why I changed in my Lossless career from Flac to wavpack to flac again. Wavpack is technically of better overall performance than flac, but flac got recently some major hardware device support by real companies.
But you and me don't need to worry, if you have your music  Losslessly as Wavpack or Flac, you made nothing wrong, in the case, one or the other format might be implemented in your next hardware device, you can transcode easily and quite (more or less) quickly.

I switched from monkeys audio to FLAC because of the above reasons.  I think that the licensing restrictions are less for FLAC and will therefore become more popular.  Also, foobar 0.91 has good embeded cue sheet support for CD image rips.  No offense to Wavpack...I haven't tried it.

Using Wavpack. One thing surprised me yesterday though.

I compressed a .wav file to .wv, maximum compression (using Dbpoweramp-with their most recent .wavpack support--I believe the newest wavpack, 4.31.

Then I decompressed the .wv file back to .wav, in a different folder, also with dbpa.

The resulting .wav file (from the decompressed .wv) was not the same size as the original .wav file! It was listed in Windows Explorer as being 1 kb smaller.

Not a significant size difference, and I could not hear a difference, in hearing the beginning of each file. Yet, it makes me wonder---did something get lost in the "lossless" compression of the .wav to .wv, that made it a different size when uncompressed back to .wav?

I'm wondering whether it is safe to delete the original .wavs, and think I still have that music in full lossless format? Is lossless not always completely loss-free? What could have accounted for that difference in 1 KB?

moi. A lossless encoder only compress the PCM data, not the actual container (WAVE or AIFF).
Meaning that when its decoded the actual filesize may differ from the original, but the content should be identical.

moi. A lossless encoder only compress the PCM data, not the actual container (WAVE or AIFF).
Meaning that when its decoded the actual filesize may differ from the original, but the content should be identical.

But since it is the same container (.wav), why would the file size be different? 

Is there any way to test whether the content is identical? (Just to ease my mind before deleting the original .wav files. 

Quote from: krmathis on 2006-04-30 18:13:54

moi. A lossless encoder only compress the PCM data, not the actual container (WAVE or AIFF).
Meaning that when its decoded the actual filesize may differ from the original, but the content should be identical.

But since it is the same container (.wav), why would the file size be different? 

Is there any way to test whether the content is identical? (Just to ease my mind before deleting the original .wav files. 

You could bitcompare the files using foobar.

Quote from: krmathis on 2006-04-30 18:13:54

moi. A lossless encoder only compress the PCM data, not the actual container (WAVE or AIFF).
Meaning that when its decoded the actual filesize may differ from the original, but the content should be identical.

But since it is the same container (.wav), why would the file size be different? 

Is there any way to test whether the content is identical? (Just to ease my mind before deleting the original .wav files. 

You could bitcompare the files using foobar.

moi. A lossless encoder only compress the PCM data, not the actual container (WAVE or AIFF).
Meaning that when its decoded the actual filesize may differ from the original, but the content should be identical.

Hrm... but WavPack DOES store the container when compressing a file. That's how it supports custom RIFF tags in WAV.

I wonder if dbPowerAMP is ignoring that information and writing default RIFF headers to the file instead.

Hrm... but WavPack DOES store the container when compressing a file. That's how it supports custom RIFF tags in WAV.

Ooops, I didn't know that.
I thought all lossless encoders compressed the PCM stream only, but I was wrong. 

I thought all lossless encoders compressed the PCM stream only, but I was wrong. 

Actually, most encoders store the extra data. Just look at the lossless comparison (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison), in the "RIFF chunks" field.

Both: FLAC for compatability these days though and I have no need to use hybrid lossy either. 

Wavpack for me ...
...although I like FLAC too. I like them both because they are open source.

WMA lossless with no particular reason. Anyway it's very fast at coding/decoding and compresses better than FLAC - I haven't had the time to try WAVPack though.

I'm about to change over from Monkey's Audio to WavPack. It's all about compression for me. WavPack high seems to be almost as good as Monkey's Audio at -3000, which is what I've always used. Decode speed is pretty nice with WavPack too, about twice as fast, so that doesn't hurt either. FLAC is a really good format too in my opinion, but the small difference in compression per album adds up to quite a bit when you have a lot of them lol. That equals many gigabytes saved in my case.

I use FLAC (for lossless and Vorbis for lossy) 'cause i love Xiph's product philosophy.

flac, because I already encoded all my CDs to it.  The quick decoding is great, transcoding flac (level 5) to ogg vorbis (Lancer) is fast enough for me.

FLAC, because of high decoding speed. (Is there a lossless codec eith higher decoding speed faster then flac?). Also i can seek in files fast (i used to compress with monkey audio and this was a problem on slower machines, even Athlon XP's)

(Is there a lossless codec eith higher decoding speed faster then flac?)

SHN 

The favorite is YALAC, not yet released.

Wavpack. On my system it compresses more, and the compression time is a lot
faster than flac.

I did not do any rough decompression time tests, and that
really does not concern me. It may be different for other purposes. I'm
more concerned with smaller size and faster speed for compression.

FLAC.

Because I've been using it for the last 3 years and have no need to switch.

- Better compression offered by other codecs are of no use to me. I'll switch when another codec can give me the lossless compression at a ratio similar to mp3's
- Fast encoding, decoding and tagging (I always pad my track when encoding)
- Low CPU usage during encoding/decoding compared to APEs
- Widespread hardware support
- Also the fact that there are no plans to introduce DRM or Lossy modes to FLAC is a great plus for me. No crap in my codec.

Also the fact that there are no plans to ... or Lossy modes to FLAC is a great plus for me. No crap in my codec.

Indeed this is another thing about FLAC. The author seems to understand to do only one thing and do it well.

Triza

flac

the first lossless I tried and there's no reason for me to switch to anything else.

doesn't mean that the oder lossless codecs are bad or anything like that but the advantages/differences are simply to small for me to switch

Quote from: DXX on 2006-05-10 15:50:39

Also the fact that there are no plans to ... or Lossy modes to FLAC is a great plus for me. No crap in my codec.

Indeed this is another thing about FLAC. The author seems to understand to do only one thing and do it well.

Triza

As for doing the job well (ie. compressing music losslessly) both Wavpack and OptimFROG outperform FLAC and still offer an hybrid mode as a bonus. Last time I checked their compression ratios were better than FLAC's 

Your comment is precipitated IMO though you are right regarding one thing: FLAC does just one thing but it is far from doing it well when compared to its contenders (compression ratios and encoding speed).

If DXX thinks an hybrid mode is crap, oh well to each its own.

I think you guys are arguing from two different niches.

if all you are ever going to do is use a PC for lossless, then yes there are several alternatives to FLAC that are better in one way or another, even if you're not obsessing over a couple % difference in filesize.  that's one niche.

if you are using it outside a PC, that's another niche, and the dominant factor is usefulness: how widely is it supported?  this is directly related to codec design and to a lesser extent other factors.  some lossless codecs that are fine for the PC (optimfrog, ape, etc.) are never going to get off the PC in any significant way.

wavpack is kind of in the middle right now; it has potential to get off the PC but still has some hurdles to jump.

unfortunately, the sad fact about codecs is that fragmentation makes all of them less useful to everyone, even though it affects the PC the least.

Josh

unfortunately, the sad fact about codecs is that fragmentation makes all of them less useful to everyone, even though it affects the PC the least.

Precisely the reason why, I gotta admit, I'm not that enthusiastic about YALAC. ALS kinda bothers me too, but then again, it's the first industry-approved standard, so it had to happen sooner or later anyway.

FLAC.

Why?  Hardware support.

QUOTE(jcoalson @ May 10 2006, 18:39)
unfortunately, the sad fact about codecs is that fragmentation makes all of them less useful to everyone, even though it affects the PC the least.


Precisely the reason why, I gotta admit, I'm not that enthusiastic about YALAC. ALS kinda bothers me too, but then again, it's the first industry-approved standard, so it had to happen sooner or later anyway.

Agreed. I mean, how many lossless codecs does the world need, really? I am a capitalist in the sense that competition is always best in the world of business. But, here in the realm of what I would consider to be research by some very talented people, competition can be counterproductive. People get fragmented and choose sides, and ideas aren't shared and can end up never being put to good use, which is really unfortunate. I wish I could think of a historical example of this.

Anyway, like I've always said before, I think flac has the best combination of all-round features, and that's why so many people use it. It has become widely accepted based on its merits, not so much what people say. For yalac, why not try to integrate that work into one of the existing codecs? Until a major breakthrough in the world of lossless waveform compression comes along and compresses those files down to say 30% (and who knows if that is even possible), do we really need so many variations which all basically compress files to within 5% of each other? Meanwhile, the price of hard disk space continues to drop...

FLAC.

Because I've purchased music in FLAC, and how widely it is supported.

People get fragmented and choose sides, and ideas aren't shared and can end up never being put to good use, which is really unfortunate. I wish I could think of a historical example of this.

It happens all the time in software development. Take a look at KDE and Gnome desktops--if they agreed to sort out their ideological differences, desktop Linux would benefit a lot. At least they're open source, so features in one may quickly be duplicated in the other.

WavPack because of its incredible performance. i've done some tests in compression on various cds and WavPack almost always compresses better than FLAC. but then again, i mostly use lossless for storage so...

WavPack. For CUE sheet support, speed and RG support.

I hope you guys are all voting in the Which lossless audio codec do you use? (http://www.hydrogenaudio.org/forums/index.php?showtopic=43928) thread also.

I'm very suprised that there are so few votes there compared to this thread.  Maybe running both at the same time was a mistake.

I hope you guys are all voting in the Which lossless audio codec do you use? (http://www.hydrogenaudio.org/forums/index.php?showtopic=43928) thread also.

I'm very suprised that there are so few votes there compared to this thread.  Maybe running both at the same time was a mistake.

What? You mean there are other lossless codecs

I voted in the other one too.

unfortunately, the sad fact about codecs is that fragmentation makes all of them less useful to everyone, even though it affects the PC the least.

Josh

I don't know. Are you saying that having options is a bad thing in the codec world? How come having choices could decrease the usefullness of something?

Maybe I'm oversimplifying, but following your logic we should all drop vorbis, aac and wma in favour of mp3 because it is much more widespread (in the PC and in the portable world) after all they do the same thing and mp3 is good enough for most people... So Garf, Ivan and Menno quit now from Ahead and join LAME development's team, yay!!

<ironic mode on>
I understand your concern: FLAC got there first, but holding the position is really hard in a competitive world so the less codecs to compete against the better. It is not the case at this time but God forbid Wavpack gets wide support from portable players!! 
</ironic mode off>

Please don't take the above as a personal attack to either Josh or FLAC. I like both, but sometimes I disagree.

I actually don't care whether or not the final lossless standard is FLAC, as long as it is as free as FLAC is.  if it turns out to be wavpack, great.  if it turns out to be mpeg-als, not so great (because of patents).  apple lossless, even worse since it's inferior by all measures.

competition is fine but the usefulness of codecs/formats is dominated by the network effect, which is harmed by fragmentation.  c.f. vhs vs. beta, bluray vs hd-dvd.  at some point you have to stop, take stock of the current technology, and agree on one format to kickstart the network effect.  repeat 10-20 years later.

like I said before, having codec options on the PC is less of a problem.  but it does reduce usefulness everywhere outside the PC, in support, distribution, etc.

Josh

Ok. Point taken. Thanks for your input.

I have to throw my two cents in and say that I use FLAC.

The best part of this codec isn't the speed or the compression, but the foresight of the developer.  Every aspect of the codec is exceptionally well thought out.  In fact, each time I think about an improvement to the codec, I read the explanation for why things are the way that they are, and I realize that I've been preemptively outsmarted once again.

Some complain that the *encoding* speed isn't as fast as WavPack; however, I think that is rather shortsighted.  Of course, we are now in the nascent days of lossless encoding, where we each encode all of our own music.  This isn't lost on me, as I've ripped over 400 discs myself.  However, FLAC properly places the emphasis on the simplicity and speed of the decoding.  In the future, the codec wars aren't going to be won by which codec drops the frame rate of my video game less while encoding, they will be won by the *decoding* speed.  Not only are files decoded thousands of times for each encode, decoding dictates which hardware platforms (those with low processor power/battery life) support the codec.  What makes this debate even more pointless is that FLAC encodes faster than EAC can rip CDs, and anybody who's been to business school knows that in mass production it's the weakest link in the chain that matters.  Even if it were to encode twenty times as fast, we'd all be sitting here twiddling our thumbs waiting for the next CD to finish.

With regard to the delay when tagging, I'd like to first point out that this entire "problem" can be avoided with -P80000 on the command line, which is what I do (though I do agree that the default should be increased).  It is a drawback, but saying that it should be changed is again placing too much emphasis on file creation, a process that is only done once.  Putting the metadata at the front helps with streaming I believe (another FLAC strong point).  Are you really willing to sacrifice this so you don't have to take ten seconds to add another term to your command line script?

The size difference with regard to WavPack is negligible, so I don't really vote based on this.

With regard to the "lack of development", I really cannot fault the developer for getting it right the first time.  Sure, WavPack is constantly coming up with new features.  I admit that WavPack hybrid mode has a cool Voltron-esque feel to it, but I'd never use it.  Mainly, I'm a firm believer in KISS/Occam's Razor.  When I want to fax someone, I use a fax machine; when i want to copy something, I use a copy machine, and when i want a cup of coffee I use a coffee machine.  I use the best tool for the job, which is why I don't own a Brother combo fax/copier/coffee pot.  When I want lossless I use flac, and if I want lossy (which I hope never happens), I'll use OGG.

Finally, the real be all end all to the discussion is industry support.  FLAC has the blessing of Xiph as well as some major players in the hardware and software industries.  If WavPack can duplicate this in the near future, my hat will go of to the developer, but it won't be an easy task, given that the industry looks for stability.

Anyway, they're both excellent codecs, but this is why I use FLAC!

Amen. Just what I wanted to say thousands of times.

Besides just because Wavepack is catching up I will not convert my lossless collection. When you mass convert you expose yourself bugs and hw errors, human errors that could destroy your collection.

The other good thing about FLAC that each release is generally stable. There are very few of them. Besides it has nice safety features like the extensive testbed for folks like me, who compile the binaries myself. Plus the --verify option. When it comes to data I am very conservative. I do want stability and do not like a lot of change.

Besides I do use a lot metaflac and flac to alter my collection. Always command line and scripts because believe it or not it is much easier. I do not want to learn a new interface or rewrite a lot of my scripts just to be able to achieve the same effect.

Josh has to scew up big time to make me switch away from FLAC.

Triza

MojoTheDestroyer & Triza: I just want you to ask about the error robustness of FLAC. 
I have read somewhere that it's not as robust as WavPack's...? 
...and because I'm quite new to the lossless world (first I have chosen Monkey's Audio for it best compression) but after some reading I have chosen WavPack because I don't see any major drawback against FLAC.
Hardware support doesn't make much sense to me, because computers are everywhere so I can always convert it to lame MP3 (-V 2 --vbr-new -Y) to fit more songs and have a lower battery consumption.

Well there were some tests guruboolez did in this regard. Unfortunately I do not not have a link. And there were a few more related threads over the years. I try to tell you what I remember/know.

1st of all, it was around 2003 when I compared all these formats and wavepack was quite behind FLAC at that time. For example it was not cross-platform as far as I remember, which was a requirement for me. Or for whatever reason I had to rule out wavepack. Once this decision was made, I merely monitored the lossless codecs by reading the relevant threads here in HA in case there is some significant breakthrough. This has not happened yet, so I did not bother to study other lossless codecs. I am still quite happy with FLAC. Hence my wavepack knowledge on your question is zero.

Well there are 3 things to consider

1) Error detection. That is to say that the encoder can detect any errors.

FLAC does that. It can detect corruption in the stream, but that is not 100% of course. But that is a 2nd line of detection. This is an MD5 sum which is calculated over the entire signal excluding the metadata. After a demod or integrity check, FLAC does check this checksum. If it fails it issues an error. Time to time I run flac -t just to test the integrity of my backup with this.

2) Error recovery. That is to say that if there is an error, the decoder is able to skip the corrupted area and it is able to recover a and continue decoding once the stream becomes healthy again. So depending on the length of the corruption, you might just hear a little blip. A lot of lossless formats cannot do that AFAIK. They instead stop once a corruption occurs. So you cannot decode anything that lies behind the corruption.

FLAC format does error recovery. Here (http://www.hydrogenaudio.org/forums/index.php?showtopic=39964) is a thread on this.

3) Error correction. This is self explanatory. To my knowledge no lossless codec is able to do that. Frankly that would be counterproductive. Error correction would be only possible by introducing redundancy, which would increase the bitrate. Lossless codecs are to compress as much as possible. This is called source coding. Error correction IMHO should be a separate thing. You digital channel or storage medium should have sufficient capability to do that.

Personally I think 1) is an absolute must including some sort of a reliable checksum like MD5. 2) is nice. I do not want 3).

Triza

MojoTheDestroyer & Triza: I just want you to ask about the error robustness of FLAC. 
I have read somewhere that it's not as robust as WavPack's...? 
...and because I'm quite new to the lossless world (first I have chosen Monkey's Audio for it best compression) but after some reading I have chosen WavPack because I don't see any major drawback against FLAC.
Hardware support doesn't make much sense to me, because computers are everywhere so I can always convert it to lame MP3 (-V 2 --vbr-new -Y) to fit more songs and have a lower battery consumption.

I hope you guys are all voting in the Which lossless audio codec do you use? (http://www.hydrogenaudio.org/forums/index.php?showtopic=43928) thread also.

I'm very suprised that there are so few votes there compared to this thread.  Maybe running both at the same time was a mistake.

Sure! Voted there too.

Hi, I'm new with wavpack and I wonder if it's possible to extract the cue sheet from a .wv as we do with FLAC (metaflac  --export-cuesheet-to=FILE thefile.flac) or the only way is using foobar ?

Thx

WVUNPACK.EXE or WAVPACK.EXE cannot do this, although I have seen discussion with David regarding the ability to automatically extract the cuesheet upon decoding.  This would be double-ace for a self-extracting file IMHO.

My latest mod of Case's Tag (http://synthetic-soul.co.uk/tag/) will let you do this quite easily, e.g.:

TAG.EXE --tocuea myfile.wv

Code: [Select]

--tocue <scheme>  : output cuesheet tag to file, name generated from <scheme>
--tocuen <name>   : output cuesheet tag to file <name>
--tocuea          : output cuesheet tag to file, name generated from source

FLAC. Better name. Better file-extension.

But I don't use lossless much, because it's largely a waste of space. Ogg is my thing.

The best part of this codec isn't the speed or the compression, but the foresight of the developer. Every aspect of the codec is exceptionally well thought out. [..] FLAC properly places the emphasis on the simplicity and speed of the decoding. [...] The size difference with regard to WavPack is negligible, so I don't really vote based on this. [...] FLAC has the blessing of Xiph as well as some major players in the hardware and software industries.

Couldn't have said it better, but I can be more brief

Quote from: MojoTheDestroyer on 2006-05-17 22:05:25

The best part of this codec isn't the speed or the compression, but the foresight of the developer. Every aspect of the codec is exceptionally well thought out. [..] FLAC properly places the emphasis on the simplicity and speed of the decoding. [...] The size difference with regard to WavPack is negligible, so I don't really vote based on this. [...] FLAC has the blessing of Xiph as well as some major players in the hardware and software industries.

Couldn't have said it better, but I can be more brief

*lol* A typical statement for a DAE guy ;D ;D ;D

Well, my 2 Cents:
Im also a convinced FLAC-user, it's fast and flexibel. Moreover, it enjoys a lively "scene" around this
codec making it imho to the codec with best future prognosis.

WavPack.

I started using lossless compression at just about the same time that Rockbox was ported to the iriver H100 series.  WavPack was functional before FLAC in Rockbox, so I chose WavPack.

Since then, I simply haven't had any good reason to switch.  Hardware compatibility is not really an issue.  My portable players run Rockbox and I use Foobar on my PCs, so WavPack is available everywhere I need it to be.  (Besides which, I use 3.97b2 -V5 --vbr-new most of the time for portable use, and WavPack is mostly for archiving.)

Accidentially mad a NULL vote.

I'm planning to move from OptimFrog to WavPack due to tag, speed and size considerations (Optimfrog needs too many CPU cycles and I have plenty of
space left)

correct me if im wrong, but flac doesnt support higher bit depths and samplingrate.
as i use lossless audiocodecs for archiving my audio projects, i use wavpack, since it also supports 24 bit etc...

is flac still lacking those features?

correct me if im wrong, but flac doesnt support higher bit depths and samplingrate.
as i use lossless audiocodecs for archiving my audio projects, i use wavpack, since it also supports 24 bit etc...

is flac still lacking those features?

FLAC supports 24-bit audio fine. My understanding is that the FLAC format also handles 32-bit ints, but the reference encoder does not implement it, and FLAC has no support for float data. WavPack handles all integer bitdepths up to 32-bit and also 32-bit floats.

Both codecs handle all sampling rates.

When i use lossless (rarely) it's FLAC.
Both developers seem to be cool, yet FLAC sounds cooler I think

WavPack user.

Single File w/ embedded cue and eac log with -h

To me, WavPack is the perfect balance between the compression size of Monkey's Audio and the Decoding Speed of FLAC.  Plus if I need another lossless type for playback in hardware...pop it into foobar2000 and convert. Done!

After all, we have all chosen lossless so that we are not stuck with ONE format. 

- Gow

Monkey's Audio 3.99 user (4.01b2 GUI) and batch files.

I liked what Gow had to say and decided to say that I happily broke from the pack and voted other!

I just wish it would store a checksum of the raw pcm data and support piping like flac.

Another great thing about FLAC is the --apply-replaygain-which-is-not-lossless switch in the reference decoder. I use it all the time when I convert to lossy (Ogg Vorbis) so that I do not have to replaygain the lossy files. This is important for me because my HW player do not read the replaygain tags. If FLAC decoder did not have this I could work around that, but it is nice to have it.

Triza

@bryant

ah youre right, foobar doesnt put the highest bit depth to 32 per default. so i encoded at 16 all the time.

Another great thing about FLAC is the --apply-replaygain-which-is-not-lossless switch in the reference decoder. I use it all the time when I convert to lossy (Ogg Vorbis) so that I do not have to replaygain the lossy files. This is important for me because my HW player do not read the replaygain tags. If FLAC decoder did not have this I could work around that, but it is nice to have it.

Triza

Foobar can do this as well when using the embedded converter for any supported codec. I use it all the time to encode my wavpacks to ogg vorbis. 

i just tried flac compared to wavpak and must say that wavpack has a slight better compression rate.

Quote from: Triza on 2006-06-30 21:20:29

Another great thing about FLAC is the --apply-replaygain-which-is-not-lossless switch in the reference decoder. I use it all the time when I convert to lossy (Ogg Vorbis) so that I do not have to replaygain the lossy files. This is important for me because my HW player do not read the replaygain tags. If FLAC decoder did not have this I could work around that, but it is nice to have it.

Triza

Foobar can do this as well when using the embedded converter for any supported codec. I use it all the time to encode my wavpacks to ogg vorbis. 

OK, but I only use Foobar only for playing on my media PC. The main rig is Linux and I do convert with scripts.

Triza

Monkey's Audio 3.99 user (4.01b2 GUI) and batch files.

...

I just wish it would store a checksum of the raw pcm data and support piping like flac.

The version at shntool (http://www.etree.org/shnutils/shntool/) supports piping; I used it to convert my APE collection to WV.  I'm not sure if it supports STDIN, but definately STDOUT.  I think it will do both.

I use Flac because.....

1. Has Hardware Support
2. Is Actively Developed (Thanks Josh!)
3. Widespread Software Support
4. So I can wear my FLAC shirt without being a liar!

 

I use Monkey's.  It compresses better than either. I don't care about how fast it seeks or its license, or any of that other stuff as I'm not an idealist, nor do  I use it for anything besides archival purposes in ape+cue.

Quote from: greynol on 2006-06-30 21:07:33

Monkey's Audio 3.99 user (4.01b2 GUI) and batch files.
...
I just wish it would store a checksum of the raw pcm data and support piping like flac.

The version at shntool (http://www.etree.org/shnutils/shntool/) supports piping; I used it to convert my APE collection to WV.  I'm not sure if it supports STDIN, but definately STDOUT.  I think it will do both.

Thanks Synthetic Soul.

I've used the version that you mentioned; I just wish the developer would implement it himself.

WavPack because of its awesome hybrid mode. I'm currently ripping all my cds to the hybrid mode with 320 kbps lossy. i'm gonna burn all the correction files to a DVD-R in case i need to transcode to lossy or to burn an audio cd.

I tried FLAC too, i'm blown away by it's decompression speed (it was like 147 X) but WavPack has better compression speed. i'll be sticking with wavpack.

I've used the version that you mentioned; I just wish the developer would implement it himself.

Ah, sorry; sucking eggs and all that.  Yes.  It seems stupid to not implement piping in the default encoder/decoder.  One of the many reasons that I appreciate WavPack more.

Quote from: nyarlathotep on 2006-04-24 22:31:38

I use WavPack.
(Yes I like the red foobar2000 wv icon)

Unfortunately, I'm quite unhappy when I use Linux. There are few options then.
Basically I just dislike XMMS.
Quod Libet is a really nice piece of program but just refuses to play some of my wv files while other just play fine. Me being blind or something?

Quod Libet uses the gstreamer-wavpack plugin and there are some problems with earlier versions (like 0.8) of that. I don't know my way around Linux yet to know how to upgrade, but that's what you need to do (you might need an updated app also, I don't know). The problem was that WavPack "high" mode files crash the plugin. And, files before 4.0 will not work either, in case you have some of those. I have the same problem with Rhythmbox.

Hope this helps... 

I updated everything (Ubuntu, GStreamer and Quod Libet) in the last weeks and now everything works fine indeed. Now I'm a happy man using Linux AND WavPack.

You're a great guy bryant.

I Use Monkeys Audio
(http://jacklewis.home.bresnan.net/small_monkey.gif)

I switched from FLAC to WavPack almost a year ago. It's fast, and it's compression is better. I've tried all the others too, but WavPack beats them all, for one reason or another.

Jim

I use FLAC, because of it's faster decoding speed. I don't care for those few per cent of extra compression

I use FLAC, because of it's faster decoding speed. I don't care for those few per cent of extra compression

Just to be sure: you know about -f option of WavPack, right?

FLAC is my preferred codec.

It is a standard, it does what has to do and it doesn't change every few months.
I don't have to upgrade filters, firmware, re-encode my files etc all the time.
That makes it that I even can buy and exchange music in FLAC and that there is hardware support.

Also, I like the Vorbis tags. Located at the beginning of the file so the metadata is read fast and indexing of my libary (I do that often) isn't that time consuming.

Thread closed.

Use the new thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=51493).  Recent posts moved there.