Skip to main content
Topic: Archiving Audio. WavPack; stick or twist? (Read 10437 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Archiving Audio. WavPack; stick or twist?

Reply #50
About 3% judging from the graphs. It's essentially free compression, so while not too big, I see no reason not to make use of it.

Archiving Audio. WavPack; stick or twist?

Reply #51
About 3% judging from the graphs. It's essentially free compression, so while not too big, I see no reason not to make use of it.

Not compatible with anything? Not open source? IMO it will die together with all the others non FLAC, ALAC.

Archiving Audio. WavPack; stick or twist?

Reply #52
About 3% judging from the graphs. It's essentially free compression, so while not too big, I see no reason not to make use of it.


To expound upon eahm's post; Being closed source and platform locked completely eliminates this format from the running for me. I don't run Windows. I don't want to run Windows. I don't want to support anything that won't support my platform independence.

I export my FLAC library via both NFS and DLNA on my local LAN. It's directly supported and playable on every network connected device in my house including AVR's of multiple brand, phones and tablets, and TV media streaming devices (Roku, WD Live, Kodi [XBMC], etc). For me Tak might as well be a stream of random garbage because it's unplayable on any of these devices.

I also run my own MPD streaming server which transcodes my FLAC library to Vorbis for streaming to me when I'm not at home. Again, Tak is mostly useless in this realm. While ffmpeg does appear to have decoder support, according to this thread it isn't backward compatible so even if I had encoded to Tak all along I'd be faced with the task of transcoding again just to remain compatible within the same codec family. While this may be an issue with the decoder itself, it certainly wouldn't be an issue if the code was open. I have FLAC files I encoded well over a decade ago. I have no worries whether they'll work with the currently available and future decoders or not.

Staying in the same decoding speed range Tak gains about 1% compression over FLAC -8 (source). If you throw decoding speed out the Window you can get just north of 2%. To me that storage savings just doesn't even come anywhere near justifying the massive amount of cons Tak brings to the table. To me, aside from marginal gains in compression efficiency Tak has nothing but a long a list of negatives.

Archiving Audio. WavPack; stick or twist?

Reply #53
Small differences in speed and in filesize.  I seem to recall somewhat opposite arguments about them earlier.

Fanboy zealotry at its finest!

Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

Archiving Audio. WavPack; stick or twist?

Reply #54
About 3% judging from the graphs. It's essentially free compression, so while not too big, I see no reason not to make use of it.


To expound upon eahm's post; Being closed source and platform locked completely eliminates this format from the running for me. I don't run Windows. I don't want to run Windows. I don't want to support anything that won't support my platform independence.

I'm not running windows either. CUERipper works just fine via WINE, so does takc. Decoding is handled by deadbeef and its ffmpeg plugin.

Quote
I export my FLAC library via both NFS and DLNA on my local LAN. It's directly supported and playable on every network connected device in my house including AVR's of multiple brand, phones and tablets, and TV media streaming devices (Roku, WD Live, Kodi [XBMC], etc). For me Tak might as well be a stream of random garbage because it's unplayable on any of these devices.

I am not using most of this, so it's not relevant to me. I either listen to the music on my PC, or on the go - and I'd rather use lossy for that anyway, see below

Quote
I also run my own MPD streaming server which transcodes my FLAC library to Vorbis for streaming to me when I'm not at home. Again, Tak is mostly useless in this realm.

Not relevant for me again, because with the mobile internet plans we have you'd burn through all the bandwidth within a few hours.

Quote
While ffmpeg does appear to have decoder support, according to this thread it isn't backward compatible so even if I had encoded to Tak all along I'd be faced with the task of transcoding again just to remain compatible within the same codec family.

The incompatible change was a one time change, and it was long enough ago to not be relevant anymore - and it's easily fixed by re-encoding with a new takc version (on WINE) - which the ffmpeg decoder supports. Should there be another change, it will most likely break the ffmpeg decoder, of course.

Quote
Staying in the same decoding speed range Tak gains about 1% compression over FLAC -8 (source). If you throw decoding speed out the Window you can get just north of 2%. To me that storage savings just doesn't even come anywhere near justifying the massive amount of cons Tak brings to the table. To me, aside from marginal gains in compression efficiency Tak has nothing but a long a list of negatives.

The list of cons isn't really that long: it's closed source and the developer seems MIA. If it was open source, someone could add utf-8 support. Or write their own en- and decoders, which would include hardware, as well.
Obviously, TAK is not the best choice if you want maximum hardware support. That's what FLAC excels at.

For me, not having to buy another HDD because TAK saved me ~12GB on my 254GB music collection compared to FLAC -8 (which is not 1% but 4.7%) back then, it was a good reason to go with it.

Archiving Audio. WavPack; stick or twist?

Reply #55
Small differences in speed and a filesize.  I seem to recall somewhat opposite arguments about them earlier.

Fanboy zealotry at its finest!


It's not zealotry. I have a specific set of requirements for my lossless audio library. Right now FLAC meets them all with a small penalty in overall compression efficiency vs the most efficient codecs out there. That penalty is small enough that the pros outweigh that con for me.

I wish the Tak developer would free his code. That would certainly tick a lot more of my requirements, but at this point I don't know that it would ever equal the device support FLAC has. If it got close though I'd probably consider it for the space savings.

Archiving Audio. WavPack; stick or twist?

Reply #56
Yes, you already made those points.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

Archiving Audio. WavPack; stick or twist?

Reply #57
Lossless is useful for a lot of things: archiving, reference, recording, production, etc. But if I learned anything from hydrogenaudio, I'm pretty sure general playback isn't suppose to be on that list... Isn't it generally agreed here that over 99% percent of people aren't able to hear the difference between lossless and lossy (at decent bitrates)?

Archiving Audio. WavPack; stick or twist?

Reply #58
Isn't it generally agreed here that over 99% percent of people aren't able to hear the difference between lossless and lossy (at decent bitrates)?

It depends on the format and the samples.  I wouldn't go so far as to agree with some made-up statistical figure, either.

Personally, I see nothing wrong with choosing a lossless format based (at least in part) on what devices can decode it even if (hypothetically speaking) a lossy encode would be completely transparent.  Maybe I'm an oddball, but I don't keep a lossy version of every lossless title that I have and occasionally I do choose to listen to titles that aren't lossy-encoded.

On the other hand, I do think people who insist on using lossless on their 8GB portable media players are more than a little silly.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

Archiving Audio. WavPack; stick or twist?

Reply #59
Lossless is useful for a lot of things: archiving, reference, recording, production, etc. But if I learned anything from hydrogenaudio, I'm pretty sure general playback isn't suppose to be on that list... Isn't it generally agreed here that over 99% percent of people aren't able to hear the difference between lossless and lossy (at decent bitrates)?


I have all of my music ripped to FLAC, for archiving/backup reasons.

Seeing as I have 40GB of space on my Sansa Clip Zip, that's somewhere between 60-80 albums. Since I rarely have that many albums in my regular rotation, I honestly can't be bothered to transcode to a lossy format.

If you have the lossless rip, why not just listen to that, if transcoding doesn't bring any particular benefits?

Archiving Audio. WavPack; stick or twist?

Reply #60
About the only reason I'm listening to lossless on my PC is because my library is in it. Theoretically I could have kept my listening copy in lossy, and my archive copy in lossless, but I rather have one more lossless copy should something go wrong.
For portable use, the choice of a codec (lossy or lossless) can also be affected by battery consumption. FLAC is doing really great on a sansa clip+ in this regard, so it's definitely a good choice if you want to have one format everywhere. Wavpack doesn't, sadly, and TAK is not supported by rockbox. I'd use opus on that, but it's not doing great in terms of battery consumption either. So for mobile use it's still mpc or vorbis for me. I'm basing this on my test results here.

Archiving Audio. WavPack; stick or twist?

Reply #61
For portable use, the choice of a codec (lossy or lossless) can also be affected by battery consumption. FLAC is doing really great on a sansa clip+ in this regard, so it's definitely a good choice if you want to have one format everywhere. Wavpack doesn't, sadly, and TAK is not supported by rockbox. I'd use opus on that, but it's not doing great in terms of battery consumption either. So for mobile use it's still mpc or vorbis for me. I'm basing this on my test results here.

You may be right in general, but that particular comparison is not really fair. The WavPack -hh mode is specifically not recommended for portable use, and the lossy mode (which that is) also requires more CPU for decode than lossless.

A more direct comparison with flac -8 would probably be -x6, and I'll bet those runtime results would be much closer. I play WavPacks on all my RockBox'd devices (iRiver, Sansa Fuze, and iPod) and the runtimes are fine.

In any event, the OP was primarily asking about format longevity and support, and I think that it does them a disservice suggesting alternatives that aren't open source (even though I acknowledge the benefits of those formats in other areas).

Archiving Audio. WavPack; stick or twist?

Reply #62
The reason I used -hh was because I was trying to get maximum compression out of the hybrid approach - the lossy+correction version was bigger than flac 8 (or was I already comparing to TAK?), so I tried to compensate. Maybe I went the wrong way about it.

At the risk of going on a tangent, If you have the time, could you please compare the runtimes of FLAC -8 to WV -x6 on your sansa fuze? My sansa clip+ has died recently, so I can't test myself anymore.

Archiving Audio. WavPack; stick or twist?

Reply #63
Lossless is useful for a lot of things: archiving, reference, recording, production, etc. But if I learned anything from hydrogenaudio, I'm pretty sure general playback isn't suppose to be on that list... Isn't it generally agreed here that over 99% percent of people aren't able to hear the difference between lossless and lossy (at decent bitrates)?


There isn't any reason for general playback to *not* be on that list. CD is a lossless source and was intended for general playback. There are 2 main reasons to use a lossy codec; to conserve data storage space, and/or to reduce bandwidth usage during transfer or playback. In situations where those 2 things aren't a scarce or shared commodity it doesn't make sense to not playback the lossless copies, at least to me.

I use lossy (opus) on my phone to conserve storage (to get much more onto the device than I could with lossless). When I decide to stream something remotely that I didn't bother to load onto my phone (rare) I again transcode to lossy on the fly to conserve Internet bandwidth and improve playback quality due to slow and less reliable mobile networks. But, when I'm at home I play the lossless files directly over the network on every device I use there. I have 1Gbps throughout my house so streaming locally isn't a problem.

Archiving Audio. WavPack; stick or twist?

Reply #64
the lossy mode (which that is) also requires more CPU for decode than lossless.

Missed this part when I was replying, but I don't think comparing the lossy mode was unfair (the -hh part was). One of the selling points of wavpack is the hybrid capability, so it's only natural to test the lossy part for portable use.
I remember something about plans of introducing a different lossy mode for wavpack (psychoacoustics based?). Any plans/updates on that? Would that make lossy more easily decodable?

Archiving Audio. WavPack; stick or twist?

Reply #65
OTOH, use of lossyWAV would reduce the size of the file without increasing the CPU load.

Archiving Audio. WavPack; stick or twist?

Reply #66
Isn't wavpack lossy pretty much a variation of lossywav?

Archiving Audio. WavPack; stick or twist?

Reply #67
Isn't wavpack lossy pretty much a variation of lossywav?

Apparently not, if it is more difficult to decode, although I'm sure they bear some similarity.

Archiving Audio. WavPack; stick or twist?

Reply #68
One of the selling points of wavpack is the hybrid capability, so it's only natural to test the lossy part for portable use.

Yes, it's natural to test the lossy mode of WavPack on a portable device to see if it will work for you. I just thought it was a little unfair to compare WavPack to the other codecs using parameters that probably give the worst possible decode performance (and a mode that flac does not have), and then in the description say that essentially flac is really good on battery consumption and WavPack isn't.

Anyway, I created a quick test corpus using a double CD album and have started the first run (obviously this will take several days). I was a little surprised how well WavPack compressed compared to flac, but even if it's a quirky case it should not affect battery consumption much:

Code: [Select]
original WAV     -- 1478.6 MB
wavpack -fx6     --  953.7 MB
wavpack -b384cx6 --  950.5 MB (424 MB lossy part only)
flac -8          --  949.9 MB
wavpack -x6      --  940.4 MB


I remember something about plans of introducing a different lossy mode for wavpack (psychoacoustics based?). Any plans/updates on that? Would that make lossy more easily decodable?

If I ever did that it would need to be compatible with the existing lossy mode so as to not break decoders, so there would be no change in the performance either. But it's not even on my radar these days.

Archiving Audio. WavPack; stick or twist?

Reply #69
Isn't it generally agreed here that over 99% percent of people aren't able to hear the difference between lossless and lossy (at decent bitrates)?

It depends on the format and the samples.  I wouldn't go so far as to agree with some made-up statistical figure, either.

Well, I meant figuratively lol. But yeah, I should've been more clear: While of course there's no way to know for certain, surely it'd be a safe bet that over 99% of people wouldn't be able to hear the difference between lossless and say high-bitrate MP4 for most music, no?

Lossless is useful for a lot of things: archiving, reference, recording, production, etc. But if I learned anything from hydrogenaudio, I'm pretty sure general playback isn't suppose to be on that list... Isn't it generally agreed here that over 99% percent of people aren't able to hear the difference between lossless and lossy (at decent bitrates)?


There isn't any reason for general playback to *not* be on that list. CD is a lossless source and was intended for general playback. There are 2 main reasons to use a lossy codec; to conserve data storage space, and/or to reduce bandwidth usage during transfer or playback. In situations where those 2 things aren't a scarce or shared commodity it doesn't make sense to not playback the lossless copies, at least to me.

My mistake for not specifying, but I did mean so in the context of file size. If file size was a non-issue, lossy would be useless and absurd (...right?).

In my own case, lossless for general playback is impractical because I've a music library that reaches a few terabytes, and I'd rather have access to most of it from one storage device. (foobar2000 makes it easy enough to do the conversion setup all in less than a minute.)

edit: I forgot to consider file size is a non-issue for most people.

Archiving Audio. WavPack; stick or twist?

Reply #70
Apologies for bringing this topic back to life after so long but there is one other issue (related to this topic) that has just cropped up. While converting WavPack to MP3 (for portable use) in Foobar I get a CRC mismatch in several of my files. As a test I tried to convert one of these files to FLAC in dBpoweramp and I get the following message "Error converting to FLAC. Error 1 CRC errors detected, audio file corrupted". Both the original file and the converted file seem to play fine through foobar without any error messages on playback.

Luckily all of the files play without any noticeable issue in foobar (I only get the CRC error when transcoding). The concern I have is that an error big enough could render a file totally unplayable.

With regards to error robustness are FLAC and WavPack formats equal? Would it be easier to recover a raw PCM stream in the event of a more serious error? (although I would not know if there were any errors as described above). Thanks in advance for your comments. It seems to me the best thing to do would be to stick with WavPack (as generally suggested in this topic), re-rip from CD those problem tracks and investigate the health of my external hard drive.....

Archiving Audio. WavPack; stick or twist?

Reply #71
I don't think there's any difference between FLAC and WavPack with respect to error robustness, and it is extremely unlikely that an error would make a whole file unplayable.

For WavPack, a block detected as corrupt will simply be muted, so you get ½ second of silence, or you might get a little burst of noise (depending a little on the player). If those files are showing as corrupted, you probably will be able to hear some defect if you play them all the way through (unless maybe they read corrupt in some cases and not others). Probably a good time to back up your backup!

Archiving Audio. WavPack; stick or twist?

Reply #72
I don't think there's any difference between FLAC and WavPack with respect to error robustness, and it is extremely unlikely that an error would make a whole file unplayable.

For WavPack, a block detected as corrupt will simply be muted, so you get ½ second of silence, or you might get a little burst of noise (depending a little on the player). If those files are showing as corrupted, you probably will be able to hear some defect if you play them all the way through (unless maybe they read corrupt in some cases and not others). Probably a good time to back up your backup!


Thanks Bryant, I really appreciate your input on this topic. The files affected are 30 min plus (audio dramas). I was doing something else while listening to them so I may well of missed the audible defects you mentioned. In any case the files play from start to finish. Interestingly most of the files affected are multi-track files and each are over 100 MB. Do you think this is coincidence or would it be safer to go for smaller files (one track per file) with regards to file longevity\minimizing chance of corruption?

Archiving Audio. WavPack; stick or twist?

Reply #73
So FLAC can't handle 24 bit audio. What other codec can I use to encode my 24 bit audio? I have one 24 bit audio will it lose quality if I encode it to FLAC?
I will think about tomorrow's problem tomorrow

Archiving Audio. WavPack; stick or twist?

Reply #74
So FLAC can't handle 24 bit audio. What other codec can I use to encode my 24 bit audio? I have one 24 bit audio will it lose quality if I encode it to FLAC?

But FLAC can handle 24 bit audio, so you wouldn't lose any information by transcoding to it.

 
SimplePortal 1.0.0 RC1 © 2008-2019