Wavpack

[wazoo2u]

Errors need to be scientifically proven, not simply accounted at random. (unless we're talking about a total POS, which FLAC clearly is not).

Personally, I've not experienced a significant amount of errors in downloaded FLAC files when playing them randomly in Foobar, but then I tend to archive almost everything, and only decompress a small percentage of stuff to burn to CD. Given that, I still don't recall running into any problems with unrecoverable errors on extraction, and I'd certainly notice because it would mean that I'd have to find a replacement or trash the show (a PITA that I'd CERTAINLY recall )

I'll also throw out the suggestion that data isn't bulletproof, and that errors happen in the most robust environments. I work with a large (30TB) multimedia ingest/playout system that despite being produced by a very reputable manufacturer, often has problems with data corruption due to a multitude of variable factors.

Originally Posted by Five

I'm not sure that we can jump to the conclusion that FLAC is any less robust than any other format. Can we?

yes, we can.

it's like a mat with different *conclusions* that you can *jump to*...


(before imminent flaming ensues, this entire post is a joke.)

[ssamadhi97]

<3 Office Space

I have been working on a reponse to the issues raised by wazoo. I wanted my response to be methodical and well thought out. But I was running short on time so instead I am offering my thoughts on the issues raised in no particular order:

The fact is that wavpack DOES offer reasonably significant increases in compression over FLAC at comparable compression speeds. It is BANDWIDTH that I am concerned about since this site is dedicated to bittorrenting. I'm not concerned about archiving since you can archive in any format you want. But if an archive format offers better compression and same robustness as FLAC where is the downside? There isn't one. In addition, many people are starting to use wavpack as their archive format-of-choice. I see no reason why they should be compelled to transcode to FLAC before torrenting their files here.

I'm not sure what you mean by 'adding it to the mix'. I think, once again, you are confusing the issue of transcoding archives with permitting torrents to be offerred in wavpack format. TTD already permits APE format and yet it clearly hasn't become a dominant format. There is nothing about APE that makes it a clear winner over FLAC or WV, but it's permitted here. Logically, Wavpack should be permitted here as well since it is every bit as robust as APE.

We are both agreed that allowing wavpack here wouldn't require anyone to transcode all of their existing shns and flacs to wavpacks. It's all a matter of a logical progression: For a time we all downloaded and archived SHNs. Now we have basically switched to FLAC and to a lesser extent APE. We download and we archive them. But we still keep our archived SHNs. If we all switch to WV, we would keep our archived SHNs and FLACs. If wavpack were to be allowed at TTD it has absolutely ZERO effect on existing SHN and FLAC archives.

But I think the fundamental flaw in your argument, wazoo, is that OS compatibility, portables and hardware support are not nearly as significant as people think. For one thing there is no way of predicting what OSs, portables or hardware will reign in the future. It's pure speculation at this point to think that FLAC will be the 'flavor of the year' 5 years from now. SHN was the flavor 5 years ago but it's now technologically obsolete. The same thing can easily happen to FLAC and wavpack 5 years from now. I think it's a waste of time and energy to worry about what will be 'the' format of the future because odds are you will guess wrong. And it doesn't matter anyway, for a number of reasons:

• Lossless formats are easily converted/transcoded into each other (notice that I make no distinction between the two terms). If some future format takes over you can convert your WV or FLAC files to that format when the time comes.
• Afaik FLAC support has only appeared on one portable, the Rio Karma, and that support was recently discontinued. There just isn't much demand for lossless codecs on portables. MP3 still reigns in the portable market, in spite of the advent of superior lossy formats such as vorbis, aac and musepack. FLAC's future as the portable format of choice is far too speculative to require TTD to put all its support behind FLAC in the hopes that portables will adopt this format. TTD isn't in the business of supporting portables anyway. Furthermore, TTD allows SHN and APE. It makes no sense to allow those formats while banning WV if TTD were in the business of promoting lossless portable formats, which it is not.
• OS support doesn't matter. Wvpack's source code is publicly available. If you switch to a new OS in the future you can compile a binary and voila your wv files are up and running. In addition it will be a simple matter for programmers of successors to FB2k to program a plugin to deal with WV on future OSs. No lossless format has a lead in this area provided its source code is publicly available. Wavpack's source code is, so that's not an issue.
• In the long run hardware support (which includes portables) isn't that significant anyway. The most likely future scenario is that all devices will be computer based, i.e. they will be computers running an OS such as Linux, Windows, etc. For the reasons I gave above regarding OS support, you will easily be able to play today's formats on those future devices. Slavery to format will be a thing of the past.

I am all for encouraging development. But I do not think that picking one format and 'sticking with it' encourages development. I think you are confusing 'development' with hardware support. On the contrary I feel the best way to encourage development is to foster competition among the various lossless codecs, by being prepared to move to a different format that offers advantages over existing ones.

I can see no principled reason why Wavpack is not an acceptable format at TTD, other than the current lack of shntool support. SHN, FLAC and APE are all permitted here, and none of these formats are clearly superior to WV. I would be perfectly happy to email the developer of shntool to point out to him that an upgrade is required, so that we can adopt wavpack here without any reservations.

[Five]

You make a very convincing case for Wavpack here. In fact, you're opening my eyes with this post, thanks for that.

Yes, we need to encourage development. There's still ppl seeding new shows in SHN format, change is difficult for a lot of us. Part of this is a fear of change, and part of it is a distrust of YALAC (Yet Another Lossless Audio Codec). I mean, should we just add the best 8 codecs (other than the allowed three) tomorrow?

RainDawg has been very busy recently, his input on this topic will help this discussion along. I know he'll have something to say about portable support. Since I don't have a portable I can't give much of a valid opinion on this other than "some ppl like it and it is good to have". My only (so far ) issue with Wavpack right now is lack of SHNtool support. I expect this can be worked out, probably in the next few months. I'd also like to know that there's xACT SHNtool support for Mac users as well.

I respect your opinions and its this faith that makes me want to back you up on this--but only when there's SHNtool/TLH/xACT support.

[pmonk]

Also add that wavpack IMO is very userfriendly (i.e. easy to figure out without the use of a frontend)

[ffooky]

Originally Posted by Five

. My only (so far ) issue with Wavpack right now is lack of SHNtool support. I expect this can be worked out, probably in the next few months. I'd also like to know that there's xACT SHNtool support for Mac users as well.

I respect your opinions and its this faith that makes me want to back you up on this--but only when there's SHNtool/TLH/xACT support.

You're a mensch Five. I've already posted to the xACT group asking about incorporation or possibly a standalone frontend.

[wazoo2u]

Originally Posted by uhclem

I have been working on a reponse to the issues raised by wazoo. I wanted my response to be methodical and well thought out.

See your points. I agree that development could be encouraged by competition. I also agree that promise of adoption of FLAC as a portable device lossless format has been very, very slow to fruition.

I'm extremely excited by the concept of a portable that basically is a small computer running an OS. That would give all of us much greater flexibility when pulling stuff out of our archives.

Don't misunderstand me about converting formats. I'm more concerned about the technical pitfalls of OTHER people converting their shows, than I am about my archives. I've got way too much material to even consider re-encoding stuff, and am mostly interested in being able to retrieve, transfer and play music, regardless of the format. I believe that the community needs to support development efforts, wherever they may be. If there's a lot of action around the development of Wavpack, then it should be encouraged by adopting it's use, BUT..... .... I certainly feel that all the tools should be in place for EASY ADOPTION by the community, including error checking/correction (SHN tool) and plugins for popular players.

Thanks for making the issues a bit more clear. I'll look forward to hearing more from others.

BTW, what is the approximate compression advantage that Wavpack holds over FLAC ?.

My sense is if it (flac) ain't broke don't fix it. SHN is fading,APE never got rolling. My slow puter so dislikes APE I avoid it. Plays badly in players,decodes much,much slower. Once Wavpack has the issues mentioned resolved-let it replace APE. Encourage SHN to be sort of a "legacy" format,recommended only if one has files that are already SHN. I don't think its nessecery to have more than 3 formats,and yet I suppose there could be a "playoff" between Wavpack and Ape,temporarily.

[pmonk]

Why do people keep on thinking we are talking about that flac sucks or replacing flac with wavpack????

This thread is in response to another thread where the suggestion that wavpack be allowed on TTD!

[ffooky]

WavPack support has now been added to the most recent build of xACT. At the moment the options are fastest or highest compression but the cool thing IMO is that it is compatible with xACT's shntool tab so you can do len, info etc and correct SBEs. I don't understand how Scott managed this as I still get the 'not handled' error with WV files at shntool's command line.

I sent an email to shntool's author a while ago asking him for a new version to deal with the changes to wavpack. I haven't heard back or seen any movement, however.

I had a look at the source code for the shntool wavpack module. From what I can tell, the only think in there preventing shntool from using the new wavpack is that there is a line of code that tells shntool to exit if wavpack has a version number greater than 3.

Unfortunately I am not good enough with C++ to be sure that this is the only thing stopping shntool, or to change this and make a new compile. Perhaps some intrepid soul here could have a look at the source code and help us out.

[jazzbo]

Originally Posted by uhclem

I had a look at the source code for the shntool wavpack module. From what I can tell, the only think in there preventing shntool from using the new wavpack is that there is a line of code that tells shntool to exit if wavpack has a version number greater than 3.

Unfortunately I am not good enough with C++ to be sure that this is the only thing stopping shntool, or to change this and make a new compile. Perhaps some intrepid soul here could have a look at the source code and help us out.

When I took a look at the code -- it's all just C, btw -- yes, the version number was the major issue. But to be honest I didn't spend enough time figuring out an elegant solution. Here are the lines (168-170 in src/format_wv.c) uhclem was referring to:


if (tagcmp(wph.ckID,WAVPACK_MAGIC) || wph.version < 1 || wph.version > 4 || (wph.flags & RAW_FLAG)) {
return NOT_WV_FILE;
}


One of the problems is that the code isn't returning a wavpack version of 4 either -- it is in the thousands if I remember right. So my concern is that something else in the header format has changed as well, or the shntool code isn't interpreting the header correctly. I didn't see anything obvious on the wavpack site to document any changes. But changing the second check to like 10000 is enough to make it work.

I'm bumping this thread because shntool got updated a few days ago, and it looks like it now supports WavPack 4.0+ files:
http://www.etree.org/shnutils/shntool/

I'll have to download the upgrade and the WavPack program to see if it really does work. If it does, we may want to consider allowing this format.

[ffooky]

Only fly in the otherwise excellent WavPack ointment is that the same extension is used for both lossless and lossy files. I know size and context are likely to prevent most mistakes or confusions but I think it should be borne in mind.