And yet another would be speek's multi frontend. Allows encoding through a pipe and has an option to copy tags from the source files. Can be handy for non-foobar users and needs only the fronted and appropriate exe files (wavpack.exe, flac.exe, etc...)

@bryant
Much compliments, for this nice update of the very good WavPack.
Are you planning to add 24bit output to winamp plugin (like Flac does)?
It would be a very wonderful thing to the quality of the DSPs in the chain

I can't believe I forgot that Foobar can use command line encoders too. I'm an idiot, go shoot me now...

Thanks for the update!

I have a question. foobar2000 can play wavpack files natively can it not? So why is there a new version of the foobar2000 wavpack component?

Updated version by the author of WavPack himself. Usually he does small fixes such as increased decoding speed, etc. foobar2000 comes bundled with a copy of foo_wavpack.dll which works fine with the program for all WavPack 4 files made so far.

can anybody confirm that the wildcards in-w work?

i have the cue file, the wave and the wavpack.exe in the same directory
my command line is:

wavpack -m -t -w CUESHEET=@*.cue <infile> <outfile.wv>

i get the following error: error in tag spec: CUESHEET=@*.cue !


edit: sorry guys. i tested it on my desktop and i didn't see that there was another cuesheet, because my desktop is so untidy

The wildcard in -w currently only works in win32 (I guess I should mention that somewhere until I get it working; I've been thinking of this an EAC/foobar enhancement). Could that be the problem?

BTW, there are some updates to the *nix versions coming up soon to fix some problems that have been reported, along with a command-line replaygain scanner...

Okay, I see your update. I keep my desktop absolutely full! In fact, there are usually one or two icons off the right side that I can't actually read but I can barely grab the edge when I need them!

hi bryant. thanks for your reply. a command line replaygain scanner would be great really. i've been trying the whole day today to make a one-step solution to encode a wavefile to wavpack, embed the cuesheet, embed the logfile (which works now) and add replaygain values to the embedded cue sheet.

would be great if you could make this possible

at the moment i'm adding the replaygain values to the cuesheet afterwards with foobar which works but is not as elegant as if the wavpack.exe could do it.

Hmm. Well, you might have to stick with your inelegant solution, at least for a while.

My first version scanner will not handle cuefiles. The real purpose of the program is to give *nix users replaygain ability because they can't run foobar, and I'm pretty sure that *nix users can't play WavPack files with cuesheets either.

another question: when i have a cuesheet integrated and decompress the wv files with wvunpack.exe, is it possible to make wvunpack.exe write the embedded cuesheet to a .cue file ?

i couldn't find any option in the documentation

I don't think this option does exist... but I really like the idea.

OHHHHHHHHHHHYEAAAAA!!

That actually sounds pretty easy to implement. The cuesheet would get the same name as the wavpack file except with .cue (and convert from UTF-8 back to ANSI). But would I have to parse it and change some filenames or paths?

the best thing for maximum compatibility (or ease of use for unexperienced users) would be if wvunpack would edit the line


to the correct filename which in this case is the filename of the original wv file (or later the decompressed .wav file).

but this is not a must i think
i have no idea how much work that is for you if you'd have to parse the cuesheet

I guess, as the cuesheet would be created in the same folder as the wave file, then it would be useful to change the FILE reference to the name of the wave file that is being created (no path - just a relative reference).

It's likely that the FILE command of the embedded cuesheet will reference the WV file, so an edit will be necessary. It would make the facility a lot more useful if it made that edit for you.

Also, as WVUNPACK lets you specify the name of the wave file, it makes sense that WVUNPACK ensure that the cuesheet points to the created file.

I think what I'm trying to say is: Yes, please - that would be great.

Edit:I don't think it's a must - but as you said yourself, it would make the facility a lot easier for the novice user. Without it the feature would be midly useful - with it it would be just the job.

yep same opinion here

I guess the other consideration is self-extracting files.

It would be cool to double click on a WavPack EXE only to have it extract to a wave and accompanying cuesheet all ready to burn.

However, this then suggests making the facility compulsory, or somehow specifying the behaviour upon encoding.

Personally I think it's worth it as a compulsory feature - especially considering tags will just be lost upon decryption anyway, so it makes sense that the user will require the cuesheet to be extracted.

However, maybe this might confuse/annoy some people?


Thanks to Xenion for this suggestion. I hope it makes it in somehow.

Well, having to parse it (and all the complications that could follow) is lot more trouble than blindly writing it out there (like I blindly take it in during encode). Maybe I should have just kept my mouth shut about changing the filename!

Is it just me or does the self-extract feature produce files with all-capitalised names?

Example: CDImage.wav becomes CDIMAGE.WAV

This seems to happen to me.

Wonderful! The last piece falls into place.

I agree. Just write it out as it is. Isn't WavPack a lossless encoder, after all? So even metadata should be "encoded" and "decoded" losslessly. Personally I always embed the cuesheet with the correct file name and extension (.wav) assuming to eventually use it after extraction. This is an easy discipline to obey to.

Sergio

Edit: orthography

i also do it like that (correct filename + .wav extension) but i'm not sure if every player (is there any other than foobar that supports wv+cue?) behaves like foobar which doesn't care about the "FILE" line

(but i'm anyway a supporter of the parsing thing although i personally might not need it as i'm paranoid about correct filenames/tags)

Well, the point is, IMHO, that if you have the cuesheet embedded it really doesn't matter what the filename is in it when you play the compressed file through foobar200 (the only player I know of that can handle WavPack with embedded cuesheets). If you extract it while decoding to WAV, then you very likely need the cuesheet with the .wav filename. Winamp, with the aid of a plug-in, can handle EXTERNAL cuesheets with the .wv filename. But in this case you will need to leave the cuesheet external, not embedded (unhapply).

Sergio

is there some setting that i missed? because afaict foobar _does_ care about the file line, 0.8.3 at least does.

No, it doesn't if the cuesheet is embedded. It does, of course, if you use separate .cue and .wv files.

Sergio

Okay, here's an unstable alpha version of WvGain for Windows. Any and all testing is deeply appreciated, but please use on test files only!!

And before anyone asks, no, I am not going to add recursive scanning (at least not for a while). Next on the list is the *nix version...

http://www.wavpack.com/wvgain.zip

Enjoy!

AWESOME

I've ran it on 10 or so albums. The only thing I noticed is that the gain values are 1 number different than when foobar calculates the gain. For example, here are wvgain's values for a track:



and here are foobar's on the same track:



I guess the numbers are rounded differently? I don't think the different rounding really matters but I thought I'd post it anyway.

I rip with EAC and that means that the cuesheet will be called <name>.wv.cue and point to <name>.wv.

If we are talking novice users then I expect many of them would have the same - especially considering the "-w CUESHEET=@*.cue" functionality in 4.3 that helps users to use WAVPACK directly to encode from EAC and embed the cuesheet.

I may be missing something here - but I assume you guys must embed your cuesheet manually (i.e.: not as part of the ripping process) and possibly make manual edits to the cuesheet as well.

As Xenion said, I don't really mind about all this - I'm technically-minded enough to deal with any situation - but I think if this feature is added then it should be added for the benefit of the novice user, and therefore be very simple to use.

Excellent. Thank-you very much, David



Well, people can easily work it out: on Windows with Case's Sweep, and on *nix with shell scripts.

Yes, you're right. I rip manually to an uncompressed WAV image, then I replaygain, compress, tag, and embed the replaygained cuesheet (without any further manual edit) using foobar2000 and your excelent TAG program.

I'm thinking of autmating somehow the whole process, maybe using REACT. If I'm not mistaken also using REACT I will end up with a cuesheet containing a .WAV reference in the FILE directive of the cuesheet.

Sergio

There has been some changes to the wavegain source lately: Wavegain problems in Linux.
It should not be related, though.

smz
I use Synthetic Soul's scripts to automate the whole process. The only manual step is ReplayGaining.

BTW, it would be great to have an utility that could apply RG info to the CUE sheet. WvGain is good, but it is suitable only for separate tracks, not for CD Images. =/

It's not mine! I feel really guilty when people say it's mine. 99.9% is still Case's. I'm very pleased if the -f switch is useful to you though.
I've actually been testing REACT recently (as a replacement for my batch files), and the way I have it set up it still uses <name>.wv.cue pointing to <name>.wv. It's possible that you could get it use <name>.wav though - I'm still learning.

Sorry, don't mean to turn this into a cuesheet-embedding thread.

Apologies - I'd been using the wrong version and didn't realise that wvselfx now presents a save dialogue!

Cuesheet storage is sooooooo handy. There's nothing more easy than having every CD in one file of its own!

I have created a 4.31 beta version to fix a couple of issues with the new release and to include a more stable version of the ReplayGain scanner.

The debug mode now works correctly on win95/98 and also uses standard directories for creating the log file, for example on win2k it's /Documents and Settings/username/Application Data/WavPack.

I also updated my MSVC++ 6.0 compiler to the most recent service pack, so it's possible that some other problems that were seen might be fixed.

The way the command-line and file lists are handled have been changed in preparation for a completely redone *nix version, so any and all testing is appreciated.

The three command-line programs are available here:

http://wavpack.com/wp431.zip

For the locals, happy Thanksgiving!

edit: spelling

Hello!
Are there (important) differences between the 4.31 of Thanksgiving and the new 4.31 released yesterday ?

Not really. I updated the SDK on my compiler, so that couldn't hurt. And I added the -s option to WvGain.

I don't think you would want to continue using the beta, but there's certainly no emergency to update.

In fact, the 4.3 version is fine for everything except debug mode...

Can't seem to find the latest version of foo_wavpack.dll (ver 2.3) on www.wavpack.com
Can anyone provide a working link?

Adyton

Strange... I'm pretty sure I've seen it there before and I downloaded it (and I have a copy, in case), but it's not there anymore.

The one offered at foobar2000.org is version 2.0.b2

The one in the current foobar2000 0.8.3 special compile is 2.2 (IIRC...).

Nothing at RareWares...

Anyway, as I said, I have a copy of it if somebody needs it and it is not officially available anymore

Sergio

your right, i checked at wavpack webby too, no seperate downloadable foo plugin

i seem to be running 2.0.b2

i would like to get my hands on any later version decoders

http://www.wavpack.com/files/foo_wavpack.zip

Thank-you!

BTW, the link in Bryant's post #85 is still valid but points to an obsolete beta. The correct link to Wavpack 4.31 is http://www.wavpack.com/wavpack-4.31.zip

This thread too is obsolete (and should be closed by admin, IMHO) as there was an official announcement for 4.31 in "Validated News" here

Sergio

Some time ago i send David a PM where i asked him why the WavPack component for fb2k v0.8.3 wasen't listed on his site anymore, and here is a quote from his reply :

"The reason that I stopped distributing the plugin for foobar 0.8.3 is because Peter asked me too. He said that the version of Case's cuesheet handing stuff that's in there is buggy (and I suppose he wants people to be using the new version which has WavPack native). Anyway, I just removed the link; the plugin is still there:

http://www.wavpack.com/files/foo_wavpack.zip

BTW, there's a bug in there that was fixed just this week but obviously won't get into the foobar plugin for 0.8.3 (but will get into the 0.9 release). If you try to repeat just a single track that has an MD5 sum, the seek back to the beginning will fail. Not a huge deal, but be aware..."