Over the years I have built up an extensive audio collection comprising several hundred gigabytes of music and dramatizations; they are currently stored in the lossless format WavPack.
More recently I have been thinking of format longevity i.e. will I need to later transcode my WavPack files to something else?, or is there a risk of eventually losing the ability to use them entirely? Presumably FLAC, or perhaps ALAC, would be better codecs for longevity as they are better supported and more popular.
With this in mind I would be very interested on hearing other peoples opinion on this question:
Is it worth transcoding my lossless collection to FLAC, or another codec, to maximize longevity?
Bear in mind this will take a while to do, but I am happy to do this if it means switching to a more future-proof codec. The collection is growing and I do not want to rip my cd's again or keep transcoding between audio formats.
Eldridge (2010, p. 9) suggests that the best lossless format for longevity would be uncompressed PCM and if this is not viable then FLAC; although Eldridge (2010) talks about the availability of suitable software a bigger issue might be if a compressed lossless codec was left behind with developing technology. However, another thing which may be important in archiving audio is error handling; based on my very limited understanding of this both WavPack and FLAC codecs will still decode if part of the file contains an error, which would not necessarily be the case with WAV or AIFF.
The link for Eldridge (2010) is:
https://siarchives.si.edu/sites/default/fil...ation2010_0.pdf (https://siarchives.si.edu/sites/default/files/pdfs/digitalAudioTapesPreservation2010_0.pdf)
Apologies for my rather long first post. Please bear in mind mind that this post is not about quality (they are all lossless) or even storage space, simply longevity. Thanks in advance for your comments.
[Additional information: I am using Windows. The cds were ripped via EAC. I use Foobar2000 on my PC and convert the lossless files to LAME V0 for my portable device]
------
AJS42
I would not even consider PCM (wav) if you want any kind of useful tags.
pdq: I would not even consider PCM (wav) if you want any kind of useful tags.
I am not saying that raw PCM is definitely the way to go, but my understanding is you can tag with AIFF.
It is important to remember that, as you said, you're talking about lossless, and converting from one to another should not cause troubles (compared with lossy).
Then, in the case that the format (wavpack in this case) was to be abandoned (which, so far, it isn't the case), there are two scenarios to consider:
Would there be transcoding programs that would still easily convert from this format to another?
If there are no programs to ease the conversion, would the wavpack commandline decoder still work?
As for the first one:
Foobar2000 can convert from the codecs it supports to other codecs.
TAudioConverter supports wavpack.
wavpack has an open source library
ffmpeg can be built (and I'd say it is built usually) with wavpack support.
As for the second one:
There exists 32bit and 64bit Windows versions, plus it can be built in Unix/linux from sources.
Taking that in consideration, it doesn't seem that de demise of wavpack is near...
[Edit]
About AIFF...
WAV and AIFF are sort of brothers. They both are based on a file format definition of the 80s named IFF (Interchangeable file format). Both are container formats and can contain data in different formats. The usual format is uncompressed PCM in different combinations of bit depths, sample rates and channels.
Tags in WAV can be added, but there is no standard and that's the reason it is not much recommended to tag them.
AIFFs have a somewhat better tagging standard, but it is mostly because AIFF is mostly an Apple format, so it has less intrusion (programs that deviate from the standard).
Other than that, WAV's are little endian and AIFF used to be big endian. I'm not sure if they still are big endian since Apple has been using intel (little endian) processors for more than a decade now.
I wouldn't bother with any of them for storage/playback.
With raw PCM or PCM containers like .wav/.aiff, if some bit gets flipped somewhere, how would you know without some external check? FLAC has frame header data checksums, frame data checksums, and a whole stream MD5 hash. WavPack has per-block output checksums and an optional whole stream MD5 hash which should be just as good for file integrity. I'd prefer either over ALAC which doesn't have any built-in integrity checks at all.
Is it worth transcoding my lossless collection to FLAC, or another codec, to maximize longevity?
Both of these formats will still be decodable long after you are dead, so I'd just wait until you have some actual reason to transcode before you do it.
Here's my solution. I use a fault tolerant and correcting file system (ZFS) which provides a level of immunity to bit rot or other disk errors. This is backed by an on-site backup, and an off-site backup.
I use FLAC, but any lossless codec for which you have access to the source code, and that code will build with an open source tool chain, is fine. I store an archive of the sources for FLAC, OGG Vorbis, Opus, and all the related libraries and tools on that same fault tolerant storage system.
In reality, if a format is going the way of the floppy disk it won't happen over night and you will have years of warning that the end is nigh. You'll have plenty of time to transcode to the new hotness if needed. If push comes to shove and my immense laziness makes me procrastinate past the point of no return I can always compile my own tool chain from the sources, and transcode using those to whatever the newer format is.
I wouldn't fear keeping everything in WavPack. Yes, it's not the number one codec for lossless audio on the web, but software-wise encoders and decoders of this format are everywhere. And it's open source, even if David will give up supporting the format for some reason, the community will eventually fork the code and keep on supporting it, at least to be compilable on new platforms.
I say keep your collection as WAVpack. It's a good high quality high bit resolution format.
Portable media players are more and more becoming like tiny little Linux computers and as computers go, codec support tends to be very manageable.
Since Rockboxed media players can play WAVpack, I think you'll be OK. Transcoding to FLAC might be losing some quality depending upon the source material.
But on the other hand, if you did decide to go with FLAC, just know that most portable players can only play the 16-bit FLACs and not the 24-bit FLACs.
Transcoding to FLAC might be losing some quality depending upon the source material.
But on the other hand, if you did decide to go with FLAC, just know that most portable players can only play the 16-bit FLACs and not the 24-bit FLACs.
I doubt the OP has 32bit files. That is the only thing flac can't compress atm or what quality loss you are talking about?
Transcoding to FLAC might be losing some quality depending upon the source material.
But on the other hand, if you did decide to go with FLAC, just know that most portable players can only play the 16-bit FLACs and not the 24-bit FLACs.
I doubt the OP has 32bit files. That is the only thing flac can't compress atm or what quality loss you are talking about?
Correct, I do not have 32bit files. The WavPack files have been converted from CD's.
Transcoding to FLAC might be losing some quality depending upon the source material.
But on the other hand, if you did decide to go with FLAC, just know that most portable players can only play the 16-bit FLACs and not the 24-bit FLACs.
I doubt the OP has 32bit files. That is the only thing flac can't compress atm or what quality loss you are talking about?
Correct, I do not have 32bit files. The WavPack files have been converted from CD's.
OH OK. I thought maybe you had 24-bit or 32-bit source files for your WAVpacks. The main advantage of lossless WAVpacks is that they can encode 32-bit float for example. But if your source materials were just CD's then transcoding to FLAC might be a good choice just to get them on something more mainstream... That way you wouldn't have to hunt as much for software and hardware that can play them. It would just take a while depending on how large your collection is. But with something like Foobar2000 you could run it overnight and aim a fan at your computer to prevent it from overheating. Good luck.
I doubt the OP has 32bit files. That is the only thing flac can't compress atm or what quality loss you are talking about?
Well FLAC cannot do floating-point. I did recently download some 24-bit floating-point file which the artist shared at Soundcloud. (But that is a different story than CD rips.)
Thanks for everyone's comments thus far, they are greatly appreciated. Based on what has been said so far, it seems to me that there is nothing wrong with my WavPack collection with regards to longevity but if I want to maximize compatibility there may be advantages of switching to FLAC at some point. That said, WavPack works fine on my computer with foobar2000. Another thing I have noticed- if I add album art it is applied much quicker (almost instantly) with WavPack than with FLAC, which takes considerably longer.
another thing which may be important in archiving audio is error handling; based on my very limited understanding of this both WavPack and FLAC codecs will still decode if part of the file contains an error, which would not necessarily be the case with WAV or AIFF.
It would surprise me if you couldn't reconstruct the "non-faulty" part of a .wav, and generally, you run greater risks of corrupting more of a file if you use compression.
However, FLAC and WavPack are checksummed formats, so errors can be
detected reliably. I did experience a file system crash (using NTFS) where files were damaged after Windows overwrote segments with segments from other files. Switching music mid-file yes. ALAC is not checksummed. Had I used that thing, I could not have verified the files except by comparing against the backup (and even then I would have to manually decide which one was faulty!)
The scenario that FLAC/WavPack become unsupported is certainly not any major worry if you use your music files. Because then you will not wake up to a FLAC-/WavPack-less world. It would fail gracefully: your new computer won't support it. I have lots of others with FLAC playback, and plenty of time to transcode should it be abandoned.
Another thing I have noticed- if I add album art it is applied much quicker (almost instantly) with WavPack than with FLAC, which takes considerably longer.
This is due to how the different formats store metadata. WavPack sticks its metadata at the end of the file. So if you add cover art it's essentially just tacking on more data to your file, which is really fast to do. FLAC puts metadata at the beginning of the file. So if there's not enough padding space to fit your cover art at the beginning, the whole file has to be rewritten to fit the image you're adding.
Had I used that thing, I could not have verified the files except by comparing against the backup (and even then I would have to manually decide which one was faulty!)
Actually, you could have used CUETools to do that, provided you had full album rips.
On topic, as others said, if you're concerned purely about longevity, there is no reason to switch from one lossless codec to another. Compatibility-wise, FLAC is unbeaten.
Personally, I'm more interested in space efficiency, so I went with TAK. Everything I need to play it, plays it. For everything else I transcode to a lossy format like ogg or opus.
Had I used that thing, I could not have verified the files except by comparing against the backup (and even then I would have to manually decide which one was faulty!)
Actually, you could have used CUETools to do that, provided you had full album rips.
Yes, that is of course a tip for those who experience similar issues. One cannot count on verifying every rip (not even in my case where I have complete rips with AccurateRip identification in tags - evidently some submissions were purged from the database), but one can get the number down.
But to stay reasonably on topic, as you point out: the big issue is not how well FLAC/WavPack is going to stay supported.
Myself I got way worse issues with a 20 years mature file system on the world's most common desktop OS, because of a fishy USB connection and the OS' default of write caching.
I would just keep it simple. If it works then theres nothing to be done. Old versions of foobar will run just fine in portable mode decades from now and even if Windows dropped the win32 api (which won't happen) then setting up a little VM with foobar is easy . The decoder is open so most software players support it.
TAK - the best lossless
FLAC - widely supported
TAK - the best lossless
FLAC - widely supported
TAK would not be the best solution for me; it is closed source so this could be a problem for longevity. Moreover, the hardware and software support is not as good as other codecs.
TAK - the best lossless
TAK is good but what makes you say it's the best? If you value size, there are codecs that compress better. If you value speed, FLAC is faster to decode. If you value openness, for example FLAC, WavPack and ALAC are open source. The best codec depends on your needs.
TAK - the best lossless
TAK is good but what makes you say it's the best? If you value size, there are codecs that compress better. If you value speed, FLAC is faster to decode. If you value openness, for example FLAC, WavPack and ALAC are open source. The best codec depends on your needs.
Balance of size, encoding and decoding speeds is what makes it the best for me. It's closed code nature is a big disadvantage, but I doubt wine stops working even should Microsoft float up belly up. As such, I don't think the encoding part is threatened in the long run. As for decoding, ffmpeg has an open source decoder, so it can be compiled whenever necessary.
I'm currently looking at optimFROG though, if the encoding gets a bit faster in that asynchronous version that is in planning (edit: that, and the deadbeef decoder plugin with tagging support), I might consider switching.
TAK - the best lossless
TAK is good but what makes you say it's the best? If you value size, there are codecs that compress better. If you value speed, FLAC is faster to decode. If you value openness, for example FLAC, WavPack and ALAC are open source. The best codec depends on your needs.
Balance of size, encoding and decoding speeds is what makes it the best for me. It's closed code nature is a big disadvantage, but I doubt wine stops working even should Microsoft float up belly up. As such, I don't think the encoding part is threatened in the long run. As for decoding, ffmpeg has an open source decoder, so it can be compiled whenever necessary.
I'm currently looking at optimFROG though, if the encoding gets a bit faster in that asynchronous version that is in planning (edit: that, and the deadbeef decoder plugin with tagging support), I might consider switching.
Interesting. It is important to note that OptimFROG is also closed source and it's hardware and software support is the same as TAK. I may be a little paranoid about longevity but an open source lossless codec is preferable to me as a long term archive solution.
True, but according to this (http://www.hydrogenaud.io/forums/index.php?showtopic=109553&view=findpost&p=902273), open-source reference implementation is in the works.
True, but according to this (http://www.hydrogenaud.io/forums/index.php?showtopic=109553&view=findpost&p=902273), open-source reference implementation is in the works.
Good stuff.
You have all put my mind at rest with regards to lossless encoding and longevity.
This is more out of interest:
With regards to FLAC, does anybody see any advantages of using FLAC uncompressed? The fact that this is uncompressed could it be better for longevity i.e. would it be easier to extract the audio data if the flac decoder suddenly became inaccessible to the user? Personally I am struggling to see the point of it otherwise. The advantages of it over AIFF and Wav (e.g. error handling and better tag support) remain, however, although taking up more space than compressed lossless codecs.
With regards to FLAC, does anybody see any advantages of using FLAC uncompressed? The fact that this is uncompressed could it be better for longevity i.e. would it be easier to extract the audio data if the flac decoder suddenly became inaccessible to the user?
No.
Personally I am struggling to see the point of it otherwise.
Uncompressed FLAC is for audiophiles. More stupid = more audiophile.
More stupid = more audiophile.
Beautiful, we need a t-shirt.
Kohlrabi's signature: "It's only audiophile if it's inconvenient."
With regards to FLAC, does anybody see any advantages of using FLAC uncompressed? The fact that this is uncompressed could it be better for longevity i.e. would it be easier to extract the audio data if the flac decoder suddenly became inaccessible to the user?
Not likely. "uncompressed" does not mean you can open it in an editor, cut away the file header and tags section and rename it to .wav - it is still a different format.
Why does it exist? FLAC has an option to store individual subframes "verbatim", and that guarantees that FLAC can always "compress to original size" (plus headers) no matter how bad the signal is. Applied on each small encodable chunk, that is a wise design.
Forcing it to use that consistently through a file is useless for ordinary use, but could be convenient for testing purposes - for example to demonstrate what the "L" in "FLAC" means. And to sell FLAC to those iddjuts who still insist that they hear differences - I don't blame Spoon.
FLAC uncompressed
Anyone who would seriously suggest this has very poor understanding of what "lossless compression" means.
There is exactly zero difference (both auditory and bitwise) between PCM data decoded from a FLAC file and the PCM data used to encode said file.
Edit: As Porcus mentioned while I was writing my post, the option in the encoder mainly exists as a "failsafe" to ensure that any compression done by the encoder does not yield
worse results than the original data.
With regards to FLAC, does anybody see any advantages of using FLAC uncompressed? The fact that this is uncompressed could it be better for longevity i.e. would it be easier to extract the audio data if the flac decoder suddenly became inaccessible to the user?
Not likely. "uncompressed" does not mean you can open it in an editor, cut away the file header and tags section and rename it to .wav - it is still a different format.
This is what I thought. I have never used FLAC uncompressed, nor do I intend to. Many museums archive their audio in raw PCM (often WAV) as they are worried about compatibility and longevity (not being able to read the file in the future); hence the original post. It seems to be, and based on the comments detailed in this thread, that if you are using an open source compressed lossless format (e.g. FLAC or WavPack) then you should be very low risk of the latter happening. Furthermore, using these codecs provide the added befit of saving space while offering error handling.
Changing your last question a bit, but there are certain advantages to encoding to a lower level of FLAC compression: some older devices might struggle with the decompression, possibly introducing skipping into playback. So in a (very) broad meaning lower compression level means better compatibility across all devices. That said, my old sansa clip+ had no troubles even with non-subset files (aka levels 9+), so it's really a moot point mostly.
Many museums archive their audio in raw PCM (often WAV) as they are worried about compatibility and longevity (not being able to read the file in the future);
I think a much bigger reason is that stable, open lossless formats are relatively new, whereas a lot of archives are very conservative with adopting new technology and will likely wait quite a while before adopting new technology.
Museums have good reason not to change media format too often. One is that they do not only need a catalog over objects, but over formats as well. What happens if they find out, in a hundred years, that a file was not converted - but remained in a format that became obsolete sixty years ago?
That won't happen to you if you actually play audio more often than you replace your computer.
Changing your last question a bit, but there are certain advantages to encoding to a lower level of FLAC compression: some older devices might struggle with the decompression, possibly introducing skipping into playback. So in a (very) broad meaning lower compression level means better compatibility across all devices. That said, my old sansa clip+ had no troubles even with non-subset files (aka levels 9+), so it's really a moot point mostly.
I am currently using WavPack fast mode, but if I decide to switch to FLAC (to increase compatibility), I was thinking of just using Level 1. After a quick test the difference in file size between L4 and higher is very small.
Lord of the Rings, Return of the King Soundtrack. Into the West (5.48).
codec (compression)
Wav: 58.48 mb (0%)
WavPack fast mode:27.49 mb (53%)
FLAC Level 0: 29.23 mb (51%)
FLAC Level 1: 28.25 mb (52%)
FLAC Level 2: 28.21 mb (52%)
FLAC Level 3: 27.10 mb (54%)
FLAC Level 4: 26.18 mb (56%)
FLAC Level 5: 26.16 mb (56%)
FLAC Level 6: 26.16 mb (56%)
FLAC Level 7: 26.14 mb (56%)
FLAC Level 8: 26.10 mb (56%)
I encode to level 8 mainly because I'm only going to encode 1 time, but I'll be storing forever (my lifetime at least). Processors just get faster so decoding speed doesn't matter, and even level 8 decodes so fast the load can basically be ignored on almost any modern hardware. I'm willing to take a little more time at encoding to save even a tiny amount of storage amortized over the entirety of my life.
Based on the results above I would say level 4 should be your target. That's an immense savings in encoding time over level 8 and you get almost all the compression efficiency, and better compression than you are getting from wavpack. This means you get a faster transcode and when you're done you will have gained some space efficiency for your effort.
if I decide to switch to FLAC (to increase compatibility), I was thinking of just using Level 1. After a quick test the difference in file size between L4 and higher is very small.
One album is not sufficient, but from the test at http://www.audiograaf.nl/downloads.html (http://www.audiograaf.nl/downloads.html) it looks like the "big" leap is indeed from -0 to -4 (page 5). Notice the second axis is size, not saving.
Myself I also use -8 - again, encoding is done once. And FLAC -8 still beats any non-FLAC at decoding speed (page 6) - any WavPack option would be 2.5 times as CPU-hungry or more. (For hi-rez, TAK is truly impressive ...)
Last I checked, TAK has a superior balance of compression, encoding and decoding compared to FLAC and WavPack.
And so I've been using TAK. If it somehow is no longer compatible with foobar2000 (doubtful to ever happen), I can always convert my TAK files to whatever other format I want. Lossy for portability/compatibility.
The concern about longevity doesn't make any sense to me. As long as one keeps a copy of the decoder, any dead format can easily be converted to another format.
Last I checked, TAK has a superior balance of compression, encoding and decoding compared to FLAC and WavPack.
Well that's your preferences. Given the OP's worry over long term compatibility, I don't think TAK is a good recommendation - despite an open-source decoding implementation does exist through ffmpeg (does it support all TAK files, BTW?).
TAK really falls short on compatibility with both hardware, software and ... Unicode, right?
(Judging its capabilities only, I am outright impressed though. Didn't think it was possible to achieve this without a research team, if at all.)
So far, the FFMPEG decoder could decode all TAK files I have. From what I know, there was a change between TAK versions that broke compatibility with older files, and the FFMPEG decoder is based on the format after the change.
As for unicode compatibility, that's only a problem for the official binaries. You can use a simple script that renames the input to ascii, then restores the filename after encoding is done. Otherwise, foobar2000 can encode and decode TAK files with any filename.
TBeck stated unicode compatibility is one of the first items on his list, but there hasn't been any visible progress for almost two years now, so I can understand why people would decide against using TAK. For me, it's still the best option and I'm fine with workarounds needed to get it working.
re: breaking compatibility
An older version of TAK can't decode a file created with the newer version or vice-versa? There is a huge difference between the two and it should have been specified!
From what I know, there was a change between TAK versions that broke compatibility with older files, and the FFMPEG decoder is based on the format after the change.
re: breaking compatibility
An older version of TAK can't decode a file created with the newer version or vice-versa? There is a huge difference between the two and it should have been specified!
No, it means that FFMPEG can decode TAK 2.x files but can't decode files encoded with earlier version of TAK.
Current official programs (tak.exe/takc.exe/tac_deco_lib.dll) can decode files made with previous versions.
I'm not familiar with TAK because I favor open over raw efficiency for this kind of application. Having said that, a break in compatibility where the newer version effectively abandons previous version encodes is completely unacceptable. Any such occurrence would automatically disqualify any codec (and their dev) from my future consideration.
These are all no good reasons to switch IMO. Stability / established features is better than some marginal speed increase or 'better compression'. Read here: http://blog.codinghorror.com/compression-and-cliffs/ (http://blog.codinghorror.com/compression-and-cliffs/)
BTW its even more diminished returns with audio compression.
Wavpack default and -f mode is very fast both ways . Decoding will be i/o dependant on PC since its very fast. For pc playback it means nothing -zero. For playback on modern devices likely nothing . Even the heaviest mode was handled fine by my 2011 samsung phone. Transcoding maybe: but do you transcode non-stop . In practical use its probably means very little.
Also too much transcoding can introduce data loss through mistakes or crummy hardware. Check all checksums and keep the old archive for a while.
(and their dev)
That is to say the dev of the unofficial decoder, in case you overlooked the post before yours...
Current official programs (tak.exe/takc.exe/tac_deco_lib.dll) can decode files made with previous versions.
Thanks for the clarification.
These are all no good reasons to switch IMO. Stability / established features is better than some marginal speed increase or 'better compression'.
Diminishing returns aside, TAK compresses much better than wavpack, as well as flac, at roughly the same encoding speed. See the compression comparison linked previously in this thread.
Pls define "much better". 3%? 5%?
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.
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.
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 (https://xiph.org/flac/comparison.html)). 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.
Small differences in speed and in filesize. I seem to recall somewhat opposite arguments about them earlier.
Fanboy zealotry at its finest!
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.
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
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.
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.
Staying in the same decoding speed range Tak gains about 1% compression over FLAC -8 (source (https://xiph.org/flac/comparison.html)). 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.
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.
Yes, you already made those points.
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)?
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.
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?
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 (https://dl.dropboxusercontent.com/u/19330332/Clip%2B%20battery%20bench/battery_bench_summary.txt).
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 (https://dl.dropboxusercontent.com/u/19330332/Clip%2B%20battery%20bench/battery_bench_summary.txt).
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).
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.
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.
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?
OTOH, use of lossyWAV would reduce the size of the file without increasing the CPU load.
Isn't wavpack lossy pretty much a variation of lossywav?
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.
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:
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.
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.
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.....
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!
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?
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?
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.
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.
Oh I see I must've misread it. Thanks
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?
I don't think there is any advantage to going to short files, especially if that's less convenient, because a single HDD error is going to result in a single defect either way. I record FM radio shows using Rockbox directly to WavPack, and they're often over 250 MB, and I've never had an issue.
BTW, you can use the command-line wvunpack program to tell you
how many errors you have in any file by just verifying the files with the "-v" option.
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.
Oh I see I must've misread it. Thanks
Possibly you have seen that FLAC cannot handle floating-point. If that is what you want, then you are reading the right thread.
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.
Oh I see I must've misread it. Thanks
Possibly you have seen that FLAC cannot handle floating-point. If that is what you want, then you are reading the right thread.
So is it safe to use FLAC for 24 bit audio?
The FLAC format supports lossless audio at 4-32 integer bits per sample. The reference encoder, and so in practice almost all encoders, only supports up to 24 bits per sample. So feel free to use it.
The FLAC format supports lossless audio at 4-32 integer bits per sample. The reference encoder, and so in practice almost all encoders, only supports up to 24 bits per sample. So feel free to use it.
OK thanks that ease my mind
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?
I don't think there is any advantage to going to short files, especially if that's less convenient, because a single HDD error is going to result in a single defect either way. I record FM radio shows using Rockbox directly to WavPack, and they're often over 250 MB, and I've never had an issue.
I use my Rockbox'ed iRiver H120 to record cassette tapes (and FM recordings like bryant) direct to WavPack and have never had a problem. I had one recent recording reach ~650mb without any issues.