Wavpack

[pmonk]

I just want to clarify but does wavpack operate the same as shntool (i.e. ms-dos thru commands)??

I used both the Frontend and Batchenc to compress/decompress and create md5 but had no clue on how to use it outside of these 2 frontends!

[uhclem]

Wavpack is supposed to work with shntool but it appears that it no longer has full functionality with shntool since wavpack v.4.0 came out. I would expect that a new edition of shntool will come out in the near future to accomodate this.

You can, however, produce shntool output in wavpack 4.0+ format (4.2 is the current version). It is only input from 4.0+ files that shntool cannot currently handle. This, of course, means that you can't check wavpack 4.0+ files for SBEs w/o converting them to some other format.

If you mean does wavpack operate like flac, shn etc, the answer is yes it does. Wavpack has Win32 binaries available at its website that work with Multi-frontend and there is a special Wavpack Frontend like FLAC Frontend made by Speek. The only difference is that wavpack uses two separate binaries, one for encoding and one for decoding.

Making or decoding wavpack files is every bit as simple as dealing with shn, flac or ape. When making wavpack files I recommend you use '-hm' as your only command-line switch. The 'h' means 'high quality' which basically means high compression, and the 'm' tells the encoder to put a wave md5 fingerprint inside the headers.

[pmonk]

If TTD plans on allowing wavpack, what would be the best way to get a text printout of the md5's when you compress using the -m option????

[ffooky]

I think TTD should hold off allowing wavpack at least until shntool can recognise it as an input file so .st5s, conv and SBE checks are possible. Much more importantly, there's no player for OS X ;)

[uhclem]

If TTD plans on allowing wavpack, what would be the best way to get a text printout of the md5's when you compress using the -m option????
wavunpack -s *.wv

[pmonk]

Thank you sir!!!!

[lucasweb]

I think TTD should hold off allowing wavpack at least until shntool can recognise it as an input file so .st5s, conv and SBE checks are possible. Much more importantly, there's no player for OS X ;)

exactly, without crossplatform capability it's just another mkw

[ssamadhi97]

Much more importantly, there's no player for OS X ;)
o rly?
http://www.hydrogenaudio.org/forums/index.php?showtopic=31533
(and how is OSX support relevant? ;))

As for shntool's lacking support for WavPack, yea, maybe it's time to give the shntool developer a little nudge.
exactly, without crossplatform capability it's just another mkw
Poor WavPack. No half-decent lossless audio format deserves being put on one level with mkw, not even jokingly. It's just not funny. :(

As stated above, WavPack is supported on relevant platforms (EDIT: and on OSX too! :D). On top of that (and as opposed to mkw) the source code is available. AND the format doesn't suck on a technical level.

[ffooky]

Sorry, didn't read that thread properly first time around. Tagging's going to be a right PITA though.

[uhclem]

wavunpack -s *.wv
Correction: wvunpack -s *.wav :imslow:

[pmonk]

please consider that I just starting using wavpack for the first time this Saturday but when using the command wavpack using options xhmd, is it a very slow process???

[h_vargas]

wavpack rocks. period.

ffooky - no offense, but i hardly see a media player being able to play WavPack files (in .WV format) as a reason to not allow this file type. when i first got MKW years ago, it was a LONG time before i found out that WinAmp would play Shorten files... and surprise, surprise, i survived! it's almost as if it only takes a few minutes to convert the file to a playable format.

hard drive storage is cheap enough now to where storing WAV (or AIFF) files shouldn't be a problem. if it is, then one can get by with suffering with 320 kbps MP3s. (besides, if a person can't afford more HD storage, then i dare say the same person doesn't have a very good PC speaker setup to where they could easily tell the difference between an MP3 @ 320 and a lossless file.)

regardless, bottom line is: WavPack is compatibile on Window$, Linux, and OS X... that along with the facts that it compresses better (smaller files) than Shorten or FLAC, that it compresses faster than either (at least on my P4 machines), and that it's lossless compression, should be enough to be allowed as hosted files.

but if it isn't allowed for quite a while to come (or ever at all), i wouldn't be surprised. change isn't brought about easily...

[ffooky]

Everything else is workable but shntool compatibility is essential. I convert everything to FLAC because I still think it has the best chance of being THE hardware compatible lossless format and one day I'll be able to play a DVD of FLACs as easily as one can a disc of MP3s today. Two step conversion is not ideal but inability to compare directly the audio data seems to be contrary to TTD's laudably progressive insistence on ST5/FFP.

[Five]

I think we'd at least need SHNtool compatability to go ahead with it. Not being able to do a len check is a big deal, especially with the recent progress we've seen thanks to TLH and BatchEnc. Even if we allowed WavPack today, anybody who seeded it would get pages of "wtf is this??? it doesn't work!!!" like I still see happen pretty much every time APE is seeded.

[uhclem]

I'm banking on the day when hardware support won't matter a damn. Everything will be stored on harddrives and will be playable through the software of your choice regardless of format. And since all lossless formats are easily converted into each other I see no reason to worry about what the format of today happens to be. I say once someone nudges the developer of shntool to release an update to incorporate the recent changes to wavpack, wavpack should be allowed here.

Yes there will be people who will say 'wtf do I do with these files?' I think anyone who first ventures to seed wv files can post a little bit of info to help such people out. As well, a little info about wv files could be added to the FAQs here. I don't see any serious reasons to reject this format.

[uhclem]

please consider that I just starting using wavpack for the first time this Saturday but when using the command wavpack using options xhmd, is it a very slow process???
Try leaving out the x and just using -hmd.

[pmonk]

So version 3.97 is the only version that works fully with shntool.

[uhclem]

So version 3.97 is the only version that works fully with shntool.
Right, but it's now obsolete.

[wazoo2u]

OK, so I haven't really researched this, but please enlighten me. Why exactly do I want to adopt ANOTHER lossless compression format when FLAC seems to be doing a very nice job, hard drives are cheaper than dirt, and blu-ray DVD's are comin down the pike ??? Do I really want to transcode 7,000 shows ??

Seriously... I don't get it. :hmm:

[uhclem]

OK, so I haven't really researched this, but please enlighten me. Why exactly do I want to adopt ANOTHER lossless compression format when FLAC seems to be doing a very nice job, hard drives are cheaper than dirt, and blu-ray DVD's are comin down the pike ??? Do I really want to transcode 7,000 shows ??

Seriously... I don't get it. :hmm:
Who said anything about transcoding? No one is suggesting you should transcode all your shows just because new formats keep coming out. I have hundreds of SHN files archived. I sure as hell don't plan to transcode them all just because of wavpack.

I think you are really missing the point. This site is dedicated to the distribution of live music via bittorrent. If there exists a format that's every bit as easy to use as FLAC and just as robust, but offers even better compression, why shouldn't we be allowed to use it here? If a seeder were to torrent some wavpack files here I can't for the life of me see why you would object to that because harddrives are so cheap, blu-rays are coming, and you have 7,000 shows already. What's that got to do with anything? This is a total red herring.

Btw, I've got a ton of dirt I have no use for but I sure could use another harddrive. Where do you get them for less than dirt? I'd love to know.

[wazoo2u]

Who said anything about transcoding? No one is suggesting you should transcode all your shows just because new formats keep coming out. I have hundreds of SHN files archived. I sure as hell don't plan to transcode them all just because of wavpack.

I think you are really missing the point. This site is dedicated to the distribution of live music via bittorrent. If there exists a format that's every bit as easy to use as FLAC and just as robust, but offers even better compression, why shouldn't we be allowed to use it here? If a seeder were to torrent some wavpack files here I can't for the life of me see why you would object to that because harddrives are so cheap, blu-rays are coming, and you have 7,000 shows already. What's that got to do with anything? This is a total red herring.

Btw, I've got a ton of dirt I have no use for but I sure could use another harddrive. Where do you get them for less than dirt? I'd love to know.

Well, I think you're taking my humor a bit too seriously, and I don't agree about the herring (although I do enjoy it once in a while). My point is that I don't see that Wavpack offers such significant space savings and benefits that it needs to be positioned to supercede FLAC as the compression flavor of the year. I've already read several comments speculating about the future compatibility of current file formats with future OS'es. Wouldn't it be wise for the trading community to REALLY establish a preference that's a reasonable choice and stick with it ? I think it would help to encourage development and insure future compatibility. Is Wavepack easier to code and work with ? Look at how hard it has been to get hardware FLAC support. ONE vendor (RIO) actually with product, and another (Neuros) screwing around with it for a year ? It's obvious to me that they just don't see a big market, and it's to everyone's advantage to concentrate interest on ONE compression format. FLAC seems to be pretty popular, so what's the advantage of something else that doesn't offer significant gain replacing it ?

I don't see storage size as a significant issue. I paid $450 for a 120 MEGABYTE hard drive 10 years ago, and just bought a 200 GIGABYTE drive for $100. DVD archive media costs have dropped to almost the same price as TY CD's. Will Wavepack REALLY save me a lot of money on archive storage ?

My point about transcoding (storage formats) was meant to illustrate the tremendous amount of work and time that the average collector needs to devote, just to archive considerations. I should've used the term CONVERT, cause it's obvious that you got upset at the thought of TRANSCODE :D . Of course I wouldn't convert everything to Wavpack. I'd couldn't, and would need to hire a staff, just to do the job. I already have a couple of hundred DAT's full of SHN's that I need to transfer to optical.

I've dealt with this issue many times before in the TV biz, where formats and hardware change significantly over time. Archiving and market compatibility are 2 of the most significant considerations that are discussed, and these hardware/format changes are NEVER taken lightly because they have marketwide impact. I think we need to be just as conservative in promoting changes to this hobby. Is a format change what's really NEEDED ?, or maybe the efficiency of the TRANSFER method (BT) could be improved. What about bandwidth, and the changes we'll see in upstream capacity in the near future ? All of these factors impact our judgement.

I respect your knowledge and opinion, but someone needs to paint a picture of Wavepack that illustrates SIGNIFICANT gains over FLAC, in order to convince me that it would be a benefit to add it to the mix.

[pmonk]

If you read this thread several posters already gave testimonials that wavpack is a great program.

I have no plans on using wavpack but at least I spent the time understanding it and how to use it without the use of a frontend program!

Who knows, by this time next year flac can be obsolete???

[ssamadhi97]

Why exactly do I want to adopt ANOTHER lossless compression format when FLAC seems to be doing a very nice job, hard drives are cheaper than dirt, and blu-ray DVD's are comin down the pike ???
...why not?

It's just a file format - you can convert back and forth between all lossless formats at will without losing anything anyway.


btw one significant difference is that WavPack preserves nonstandard RIFF chunks, as opposed to FLAC which just discards them and slaps a canonical wav header on decoded files. Not that this should matter for people who are into live music trading, but for people who actually make use of those chunks it's a selling argument (think radio stations). iirc. [that's just random info. I know it's not actually relevant for the decision on whether to allow WavPack here or not]

[wazoo2u]

...why not?

It's just a file format - you can convert back and forth between all lossless formats at will without losing anything anyway.


btw one significant difference is that WavPack preserves nonstandard RIFF chunks, as opposed to FLAC which just discards them and slaps a canonical wav header on decoded files. Not that this should matter for people who are into live music trading, but for people who actually make use of those chunks it's a selling argument (think radio stations). iirc. [that's just random info. I know it's not actually relevant for the decision on whether to allow WavPack here or not]

I understand that it's just a file format, but it means that if I'm using FLAC as a portable device format, I'll be converting everything to FLAC, and then probably tossing the original Wavpack files, hardly a good idea when trying to preserve lineage.

I don't care if it's FLAC or Wavpack when I'm firing up Foobar. If Wavpack saves me 10% compression space, great, but it's not "the killer app" in the scheme of things.

I'm concerned with keeping FLAC in the forefront of potential portable music formats because at the very least, some development work has been done already. I think it would be in the best interests of most lossless collectors to have a really good portable device on the market, and so far, it seems that FLAC offers the most promising results (albeit slight) in achieving that goal. MP3 is dwarfing lossless usage. It seems like it's going to be difficult to develop even a niche market device. Why not encourage development by sticking with FLAC for a while and see if developers are encouraged to build hardware devices, and for that matter, the future development of FLAC to make it better ?

Your notes on radio station and iirc applications are duly noted, and that's great... for them. Are those features a benefit to lossless collectors, not according to you, and I would agree.

It dowsn't seem to me that FLAC has achieved mainstream popularity among collectors for more than 2 years or so, and it wouldn't hurt if it could live a longer life.

So again my question, and speaking from a standpoint of ENCOURAGING DEVELOPMENT, does it look to anyone else that introducing the popular use of Wavpack compressed files is taking "one step forward, two steps back" ?

[h_vargas]

see here:

http://www.thetradersden.org/forums/showthread.php?t=6262


i think FLAC is a fine format. but honestly, i've never gotten errors as bountiful with SHN/MKW (and never any error encoding/decoding with WavPack) as i have with FLAC. for whatever reason, i seem to get errors A LOT more frequently with FLACs than with any program... and mind you, it isn't a huge percentage of the time. but then again, i never have had any encoding/decoding errors with WavPack (in .WV or .EXE formats), and only very few errors with MKW - all of which were attributable to the file(s) sent not passing the MD5 checksum for the original sender either.

again, FLAC is a fine format and all. but i haven't had the same issues with the other compression formats i use. and, i could not care any less about any hardware players (portable or otherwise) that "can play FLAC files" because that's not a function i'd use. (FLAC files comprise the smallest amount of stored lossless audio data that i have in my collection. and i'm not about to convert the other shows to FLAC format.) as i've done since i started acquiring lossless Shorten files - if i want to listen on my computer, i can fire up WinAmp; if i want to listen in my stereo system or car, i simply convert and burn the files to CDR/DVDR. when i transfer a master or DAT clone to my hard drive, i compress it as an SFX .EXE file, so on any Windows platform computer, i know i can decompress the show and burn an audio copy and i don't have to have any special software installed on said computer.

[wazoo2u]

One problem that I can forsee would be the wholesale conversion of filesets already in the trading pool from FLAC to Wavepack. Yes, being able to distribute tracks as SFX.EXE's is very cool, but I'd be worried about the introduction of errors as people migrated existing files.

I dunno.. I think there's a lot of things to consider. I certainly wouldn't personally shun using a good format that I could decode to WAV, but the community needs to discuss these issues.

What kind of discussion has there been among the Hydrogen and etree folks ?

[diggrd]

... I think it would be in the best interests of most lossless collectors to have a really good portable device on the market, and so far, it seems that FLAC offers the most promising results (albeit slight) in achieving that goal. MP3 is dwarfing lossless usage. It seems like it's going to be difficult to develop even a niche market device. Why not encourage development by sticking with FLAC for a while and see if developers are encouraged to build hardware devices, and for that matter, the future development of FLAC to make it better ?

One reason for this dwarfage is file size, maybe a lossless format with the most compression is the key to success.

[Five]

Like Monkey's Audio? :D

[ssamadhi97]

i think FLAC is a fine format. but honestly, i've never gotten errors as bountiful with SHN/MKW (and never any error encoding/decoding with WavPack) as i have with FLAC. for whatever reason, i seem to get errors A LOT more frequently with FLACs than with any program... and mind you, it isn't a huge percentage of the time. but then again, i never have had any encoding/decoding errors with WavPack (in .WV or .EXE formats), and only very few errors with MKW - all of which were attributable to the file(s) sent not passing the MD5 checksum for the original sender either.

You prefer programs that don't tell you about errors and potential issues? :P

It's really the same for all formats: if the file a program is working on is broken, problems are to be expected.

[Five]

I've also had the most errors with FLAC but I think that has something to do with the fact that 98% of all shows I get these days is FLAC format. I'm not sure that we can jump to the conclusion that FLAC is any less robust than any other format. Can we?

[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.

[h_vargas]

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*... :lol:


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

[ssamadhi97]

<3 Office Space :D

[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. 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]

. 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]

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 ?.

[rerem]

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.

[uhclem]

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]

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.

[spiritinaphoto]

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.

[spiritinaphoto]

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.
Yes, but you can run wvunpack -s *.wv and it'll tell you if the files are lossless or not (see wvunpack_s.txt to see the output).

Anyway, I ran the following test and everything seems perfectly kosher on my end.

First, I got the ffp from the original FLAC files by running metaflac --show-md5sum *.flac (see XM2 - Transmission 4.1.ffp.txt). I then ran shntool len *.flac (see shntool len (flac).txt) and computed the st5s using shntool hash *.flac (see XM2 - Transmission 4.1 (flac).st5)--side note, it's now 'hash' instead of 'md5' to compute st5s.

The next step was to decompress the FLAC files, which was done using flac -d -V *.flac.

From there, I could convert the WAV files to WavPack, which was done with the command wavpack -hm *.wav. I then ran shntool len (see shntool len (wv).txt), shntool hash (see XM2 - Transmission 4.1 (wv).st5), and finally the aforementioned wvunpack -s *.wv on the WavPack files.


As you can see from the text files attached in this post and the next few posts, it worked beautifully--checksums match. Based on my observations, I'm going to put in my recommendation for WavPack to be considered an acceptable format for trading on this site. Others may run tests and see if there are any major hitches I haven't encountered in my test.

[spiritinaphoto]

The rest of the text files from the above post

[Gizby]

This is excellent news. I've been itching to upload my content as wavpack. Just need to wait for a couple of other applications to catch up, some approvals, and away I go.

[Five]

hopefully we can get support from TLH now that xAct has it. Also support for the command to differentiate lossy from lossless-encoded wavpack in non-command line form is essential. We need full support for the command line-impaired! Then it sounds great to me.

wavpack is a leader, only lossless codec to support 32bit (albeit limited support).