Help - Search - Members - Calendar
Full Version: Do you use FLAC or WAVPACK?
Hydrogenaudio Forums > Lossless Audio Compression > Lossless / Other Codecs
Pages: 1, 2, 3, 4
Badass01


Please also state your reason why...
senab
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.
keytotime
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.
toology
WavPack because of good encoding/decoding speed and at the same time better compression.
Fandango
Wavpack: higher compression
Maglor
FLAC, because my iAudio supports it. No other reason than that.
esa372
I used FLAC for quite a while, but I recently switched to WavPack (for the same reasons listed above).
vitos
WavPack - because of better compression and hybrid mode.
guruboolez
QUOTE (vitos @ Apr 23 2006, 03:45 PM) *
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 dry.gif

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.
jmartis
I've used Wavpack lossy, but I've just acquired a new 120gb harddrive so nothing inhibits me from going lossless smile.gif
ffooky
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.
lextune
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.
iGold
FLAC because of wide Linux support and embedded cuesheet metadata block (for my backups I prefer one .flac for one CD).
pepoluan
Between FLAC and WavPack I use FLAC for it's cross-platform compatibility.

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

So, there.
krmathis
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.
Synthetic Soul
This is spooky. shock1.gif

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.
Shade[ST]
Wavpack -- I like the name better.
singaiya
Wavpack for the hybrid feature. I don't use lossless for listening, but for transcoding or if I need to burn an audio disc.
Sebastian Mares
WavPack because it's faster.
slks
FLAC - more support, faster decoding.
Mo0zOoH
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).
rjamorim
Wavpack. Partially because Bryant is a hell of a great guy.
Duble0Syx
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. smile.gif 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. biggrin.gif
kwanbis
shouldn't you had inclided monkey, alac, yalac, wma lossless as choices?
gfngfgf
Wavpack, better compression
Synthetic Soul
QUOTE (kwanbis @ Apr 23 2006, 07:01 PM) *
shouldn't you had inclided monkey, alac, yalac, wma lossless as choices?
In a poll called "Do you use FLAC or WAVPACK?"? wink.gif

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.
My name is Mud
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.
Realityfreak
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.
Alexxander
FLAC -8 because of the fast decoding speed and native tags. I don't care about 2-4% less compression.
Menollo
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 sad.gif )
4. it is streamable (wavpack isn't)
DreamTactix291
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 smile.gif
CyberFoxx
Flac, mostly for the better Linux support.

Then again, I haven't even tried Wavpack out yet...
fairyliquidizer
I saw an alternative at Ikea called FLATPAC
rehgf
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.
VCSkier
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.
beto
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.
jcoalson
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
kjoonlee
I think he needs (but doesn't want) 32kb~64kb (sic) of padding.

http://www.hydrogenaudio.org/forums/index....4580&hl=padding
shadowking
QUOTE (Menollo @ Apr 23 2006, 12:33 PM) *
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 ?
kjoonlee
No implementations, maybe?
sshd
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).
user
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.
micimaci
WavPack - speed, warm fuzzy feeling
guruboolez
QUOTE (jcoalson @ Apr 24 2006, 07:14 AM) *
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
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 tongue.gif).

Nonetheless, as I reported 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):
CODE
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? wink.gif

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


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.
shadowking
I use wavpack. It is cutting edge technology, great to play with but it really does work practicaly. Amazing software and developer.
tpc
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.
Zergen
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.
yane
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).
zombiewerewolf
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.
laneling
Wavpack is better,I think.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.