Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Archiving Audio. WavPack; stick or twist? (Read 27533 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Archiving Audio. WavPack; stick or twist?

Reply #26
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.

Archiving Audio. WavPack; stick or twist?

Reply #27
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.


Archiving Audio. WavPack; stick or twist?

Reply #29
Kohlrabi's signature: "It's only audiophile if it's inconvenient." 

Archiving Audio. WavPack; stick or twist?

Reply #30
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.

Archiving Audio. WavPack; stick or twist?

Reply #31
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.

Archiving Audio. WavPack; stick or twist?

Reply #32
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.

 

Archiving Audio. WavPack; stick or twist?

Reply #33
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.

Archiving Audio. WavPack; stick or twist?

Reply #34
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.

Archiving Audio. WavPack; stick or twist?

Reply #35
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.

Archiving Audio. WavPack; stick or twist?

Reply #36
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%)

Archiving Audio. WavPack; stick or twist?

Reply #37
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.

Archiving Audio. WavPack; stick or twist?

Reply #38
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 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 ...)

Archiving Audio. WavPack; stick or twist?

Reply #39
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.

Archiving Audio. WavPack; stick or twist?

Reply #40
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.)

Archiving Audio. WavPack; stick or twist?

Reply #41
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.

Archiving Audio. WavPack; stick or twist?

Reply #42
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!

Archiving Audio. WavPack; stick or twist?

Reply #43
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.

Archiving Audio. WavPack; stick or twist?

Reply #44
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.

Archiving Audio. WavPack; stick or twist?

Reply #45
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/

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.

Archiving Audio. WavPack; stick or twist?

Reply #46
Also too much transcoding can introduce data loss through mistakes or crummy hardware. Check all checksums and keep the old archive for a while.

Archiving Audio. WavPack; stick or twist?

Reply #47
(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.


Archiving Audio. WavPack; stick or twist?

Reply #48
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.

Archiving Audio. WavPack; stick or twist?

Reply #49
Pls define "much better". 3%? 5%?