David Bryant released today WavPack 4.3
WavPack is a high quality, efficient and featureful lossless/lossy/hybrid compressor. It is available for free, including source code released under a very liberal license.
Changelog is available in next post.
Obtain the Win32 binaries and plugins at WavPack's official site:
http://www.wavpack.com/ (http://www.wavpack.com/)
And compiles for several *nix platforms at RareWares:
http://www.rarewares.org/lossless.html (http://www.rarewares.org/lossless.html)
WavPack release 4.3 changelog:
wavpack.exe (command-line encoder) - 4.3
----------------------------------------
fixed: bug causing termination error with very wide screen widths
added: command-line option (-l) to use low priority for batch operation
added: command-line option (-r) to generate a fresh RIFF header
added: debug mode (rename to wavpack_debug.exe)
added: automatically detect lower resolution data even without -x1
added: src and dst dirs are searched also for tag source files (handy for EAC)
added: wildcard accepted for tag source files (handy for EAC)
added: handle non-standard sampling rates
improved: returns error status for any error
improved: use longer blocks in multichannel files (better "high" compression)
wvunpack.exe (command-line decoder) - 4.3
-----------------------------------------
fixed: very rare decoding bug causing overflow with hi-res files
fixed: bug causing termination error with very wide screen widths
fixed: formatting error in duration display
added: command-line option (-ss) to include tags in summary dump
added: command-line option (-l) to use low priority for batch operation
added: debug mode (rename to wvunpack_debug.exe)
improved: returns error status for any error
improved: more robust decoding of damaged (or invalid) files
in_wv.dll (winamp plugin) - 2.3
nxWavPack.dll (Nero plugin) - 1.2
WavPack_Apollo.dll (Apollo plugin) - 1.3
cool_wv4.flt (CoolEdit / Audition filter) - 2.6
-----------------------------------------------
fixed: very rare decoding bug causing overflow with hi-res files
improved: handle ID3v1.1 tags (now includes track number)
improved: more robust decoding of damaged (or invalid) files
added: handle non-standard sampling rates
foo_wavpack.dll (foobar plugin) - 2.3
-----------------------------------------------
fixed: any error during WavPack file open caused crash if wvc file present
fixed: very rare decoding bug causing overflow with hi-res files
improved: more robust decoding of damaged (or invalid) files
added: handle non-standard sampling rates
WavPack Library Source Code - 4.3
---------------------------------
fixed: very rare decoding bug causing overflow with hi-res files
added: automatic generation of RIFF wav header during encoding
added: new functions to access tags by index (instead of item name)
added: automatically detect lower resolution data during encoding
added: handle non-standard sampling rates
improved: more robust decoding of damaged (or invalid) files
improved: use longer blocks in multichannel files (better "high" compression)
improved: two structures renamed to avoid namespace conflict
removed: legacy code for Borland compiler
WELCOME to the new baby, and a great THANK-YOU to David! (Yes, to you too, Roberto! )
Sergio
Thanks, Roberto.
BTW, another important item not in the changelog is the new plugin for Steinberg's WaveLab 5 that's available. Anyone who got the first one should grab the latest updated beta:
http://wavpack.gl.tter.org/ (http://wavpack.gl.tter.org/)
Thank you David !
Muchas gracias, David!
added: wildcard accepted for tag source files (handy for EAC)
Now all we need is for Andre to fix the file-extension error in EAC, and voila!, single step rip/compression/cue-embedding!
EDIT: added "rip".
Thank You David.
That -l switch will shure come in handy for archiving the mixes of our show here.
Thanks a lot! There's still the filename bug though, where a file with special chars in its name is "not found":
$ wvunpack "00 - [untitled].wv"
WVUNPACK Hybrid Lossless Wavefile Decompressor Linux Version 4.3 2005-11-01
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
file 00 - [untitled].wv not found!
On another topic, the detection of oversampled content works beautifully. I tested the stereo mix of the
R.E.M. - In Time DVD-Audio with wavpack -hm; version 4.2 produced 2.659 GiB worth of data, versus 1.846 GiB for v4.3, for the same encoding time :-)
Now all we need is for Andre to fix the file-extension error in EAC, and voila!, single step rip/compression/cue-embedding!
The file extension issue doesn't stop you doing any of these.
I don't think foobar pays any attention to the FILE command in an embedded cuesheet.
thanks alot for your great work.
Great work bryant! Much appreciated.
I also have not implemented shadowking's noise-shaping improvement because I wanted to do it in a backward compatible way (which was more work). But it's scheduled.
[snip]
However, I believe that the existing -x mode could be overhauled in a way that would give a significant improvement to compression of real music without the huge speed penalty that exists now. Well see...
[a href="index.php?act=findpost&pid=337447"][{POST_SNAPBACK}][/a]
Is this next for 4.4?
Great work! Hope WavPack keeps getting better and better.
An early Xmas present. Thank you!
Now all we need is for Andre to fix the file-extension error in EAC, and voila!, single step rip/compression/cue-embedding!
The file extension issue doesn't stop you doing any of these.
I don't think foobar pays any attention to the FILE command in an embedded cuesheet.
[a href="index.php?act=findpost&pid=339974"][{POST_SNAPBACK}][/a]
You're right Synthetic Soul, it does work, Muchas gracias!
I had tried it with an already ripped and renamed WAV and it worked, but I thought that going straight from rip to encode to embed wouldn't work because of the extra extension.
Haha, just a day after I finished archiving my dvd-a rips with 4.2 =)
I'll give it a run and see how it will handle them compared to 4.2.
Haha, just a day after I finished archiving my dvd-a rips with 4.2 =)
What a timing
OK, I reconverted one of them, and went from 4678 kbps (4.2) to 4671 kbps (4.3). Using the same settings (lossless, high).
Am I missing some kind of special switch used specifically for hires audio here?
I use -hx6 for MAXIMUM compression of DVD-Audio. I don't care how long it takes to encode, and it plays back as fast as -h that I can tell.
I use -hx6 for MAXIMUM compression of DVD-Audio. I don't care how long it takes to encode, and it plays back as fast as -h that I can tell.
Extra modes should actually be slightly faster (decoding) than -h.
Interesting. I guess thats what I get for using a frontend and not checking properly the documentation. I'll try to redo it with -hx6 and see if there are any big differences.
added: src and dst dirs are searched also for tag source files (handy for EAC)
added: wildcard accepted for tag source files (handy for EAC)
Could anyone explain what are these new features for and how do they work?
added: src and dst dirs are searched also for tag source files (handy for EAC)
If you specify "-w CUESHEET=@cdimage.wv.cue" WAVPACK will look for cdimage.wv.cue in three folders (in addition to the folders in PATH):
- The folder in which WAVPACK resides
- The folder in which the source WAVE resides
- The folder in which the WV file is to be created
Edit: obviously if you are using STDIN or STDOUT then only two folders are valid.
added: wildcard accepted for tag source files (handy for EAC)
Wildcards can be used like "-w CUESHEET=@*.cue". This will only work if there is one .cue file in the folder. It is useful when the cuesheet name changes per image, but you don't want to have to change your command line every time you rip.
I rip to a "clean" directory from EAC, so it is useful to me.
By using "-w CUESHEET=@*.cue" WAVPACK will first check the folder in which WAVPACK.EXE resides for a cuesheet. When unsuccessful it will check the directory in which the temporary WAVE file resides - where it should successfully find the cuesheet EAC just created.
Interesting. I guess thats what I get for using a frontend and not checking properly the documentation. I'll try to redo it with -hx6 and see if there are any big differences.
[a href="index.php?act=findpost&pid=340237"][{POST_SNAPBACK}][/a]
May I suggest using -hx only. I have encoded few albums with -hx and -hx6 and there was only 1-2 kbps difference in bitrate but the encoding time difference was like 3x or something.
EDIT: With albums, I mean normal audio CD's.
Interesting. I guess thats what I get for using a frontend and not checking properly the documentation. I'll try to redo it with -hx6 and see if there are any big differences.[a href="index.php?act=findpost&pid=340237"][{POST_SNAPBACK}][/a]
Honestly, I believe hx6 is madness. It takes ages to encode and won't do much better than, say, hx2 - that is several times faster.
Interesting. I guess thats what I get for using a frontend and not checking properly the documentation. I'll try to redo it with -hx6 and see if there are any big differences.[a href="index.php?act=findpost&pid=340237"][{POST_SNAPBACK}][/a]
Honestly, I believe hx6 is madness. It takes ages to encode and won't do much better than, say, hx2 - that is several times faster.
[a href="index.php?act=findpost&pid=340334"][{POST_SNAPBACK}][/a]
I agree. I've always used -hx2m for encoding any audio. It's encoding speed is speed comperable to flac and compresses a good bit better in some cases. x6 is
way too slow. Generally if it takes longer than the length of the track I would consider it too slow unless it really made difference. Glad to see 4.3 released, been busy re-ripping some stuff I ripped wrong using wavpack. Looking forward to any improvements in speed and compression in 4.4.
Just for the record, I still recommend using the -x option by itself, with no numeric parameter. In the past there was some logic to using -x1 because it would detect low-resolution files, but now this is handled by default, so there's no reason for that anymore. Please refer to this post:
http://www.hydrogenaudio.org/forums/index....ndpost&p=286569 (http://www.hydrogenaudio.org/forums/index.php?showtopic=32753&view=findpost&p=286569)
There's nothing wrong with using the numeric parameter, but using -x by itself assures that you're probably getting the best "bang for the buck" for all the extra time you're using. The only exception to this is -hx6 if you absolutely must have the maximum compression and truly don't care how long it takes (like Kazuma).
The only exception to this is -hx6 if you absolutely must have the maximum compression and truly don't care how long it takes (like Kazuma).
[a href="index.php?act=findpost&pid=340350"][{POST_SNAPBACK}][/a]
or me.
...or me, for high res audio.
-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.
Well, I have time to spare for encoding...
-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.
Have you tryed plain -hx ? I have no HiRes audio to test with.
I have no HiRes audio to test with.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=340484")
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=35624&pid=318436&st=0&#entry318436]24 bit, 96 kHz stereo sample[/url]
Hi, I can't seem to find a way to export the MD5 hashes created by wavpack to a text file.
Is this possible? How do I do it?
thanks.
-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.
Have you tryed plain -hx ? I have no HiRes audio to test with.
[a href="index.php?act=findpost&pid=340484"][{POST_SNAPBACK}][/a]
I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.
24bit/96kHz - 156 MB
WavPack -h - 95,5 MB
WavPack -hx - 78,8 MB
not bad for -hx ... but it took a long time on my P3-700
.halverhahn
I have no HiRes audio to test with.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=340484")
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=35624&pid=318436&st=0&#entry318436]24 bit, 96 kHz stereo sample[/url]
[a href="index.php?act=findpost&pid=340487"][{POST_SNAPBACK}][/a]
Apparently this sample isn't available any more...
I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.
Do you think this is representetive of true 24/96 material in terms of samples distribution?
Sergio
maybe i was searching for the wrong thing as i only found a few results but if you want some hi res stuff you could try this link (http://www.archive.org/audio/etree-details-db.php?id=22630)
Hi, I can't seem to find a way to export the MD5 hashes created by wavpack to a text file.
Is this possible? How do I do it?
thanks.
[a href="index.php?act=findpost&pid=340570"][{POST_SNAPBACK}][/a]
just figured it out
wvunpack -s "wavpack file path and/or name here" > "text file path and/or name here"
added: command-line option (-r) to generate a fresh RIFF header
i've been using flac mainly so i have a question about this option.
wouldn't it be better to have an option to not store any particular riff headers in the first place? and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?
to me this is a slight distinction between a compressed file (wavpack) vs. a compressed audio format (flac, ...).
and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?[a href="index.php?act=findpost&pid=340639"][{POST_SNAPBACK}][/a]
Can't you store headers of whatever format you support - be it WAV, AIFF or MKA - and still offer format independency?
Or are you buying into Coalson's arguments not to offer RIFF storage support?
and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?[a href="index.php?act=findpost&pid=340639"][{POST_SNAPBACK}][/a]
Can't you store headers of whatever format you support - be it WAV, AIFF or MKA - and still offer format independency?
Or are you buying into Coalson's arguments not to offer RIFF storage support?
[a href="index.php?act=findpost&pid=340672"][{POST_SNAPBACK}][/a]
personally, i haven't encountered any riff header information that i'd want to keep. that's because i mainly deal with lossless as a format for cd backups.
of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.
edit: additionally, i think that metadata should be transferred to the format's own metadata format instead of storing the original file as-is.
personally, i haven't encountered any riff header information that i'd want to keep. that's because i mainly deal with lossless as a format for cd backups.
Many people have use for the extended RIFF info, mostly people dealing with audio editing and mastering.
of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.
What's the difference for end user? IMO, WavPack just caters to a wider audience with native header storage support. For the usual CD ripping guy, using either format leads to the same experience.
edit: additionally, i think that metadata should be transferred to the format's own metadata format instead of storing the original file as-is.[a href="index.php?act=findpost&pid=340677"][{POST_SNAPBACK}][/a]
And indeed, it is stored in special locations inside the WavPack file, and if appropriate - E.G, in the lite decoder - the unnecessary data is ignored. That's how I understand it, at least.
of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.
What's the difference for end user? IMO, WavPack just caters to a wider audience with native header storage support. For the usual CD ripping guy, using either format leads to the same experience.
that's true if you are not one of those people (i.e. me) that don't like storing redundant or unnecessary data.
one could argue that using a compressor that gives larger files is against that doctrine, but i think that's another issue.
anyway, my question was not to promote flac's approach. i just think that an option to either store or not store riff headers at encode time would be a better approach than an option to remove them upon decoding. that is assuming the option only works on decoding.
anyway, my question was not to promote flac's approach. i just think that an option to either store or not store riff headers at encode time would be a better approach than an option to remove them upon decoding. that is assuming the option only works on decoding.
[a href="index.php?act=findpost&pid=340682"][{POST_SNAPBACK}][/a]
Check it again under which program this option is listed.
Check it again under which program this option is listed.
[a href="index.php?act=findpost&pid=340689"][{POST_SNAPBACK}][/a]
*blush* so that means wavpack throws away any existing riff headers, generates a new one and stores that instead of just storing nothing and generating a fresh one upon decompressing?
*blush* so that means wavpack throws away any existing riff headers, generates a new one and stores that instead of just storing nothing and generating a fresh one upon decompressing?[a href="index.php?act=findpost&pid=340691"][{POST_SNAPBACK}][/a]
Yes
I too plan to start using the new switch on my encodes from now on, as I too have no use for extra header data.
I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.
Do you think this is representetive of true 24/96 material in terms of samples distribution?
Sergio
[a href="index.php?act=findpost&pid=340582"][{POST_SNAPBACK}][/a]
Not realy but the upsampled CD-Track contains nothing above 22050hz. You see how good WavPack perform with bandlimited HD-Source material.
This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.
I have dedicated two metadata field ids for storing images of the RIFF data so that a wav file can be perfectly recreated (one is for RIFF data that comes after the audio). But these fields are not required to interpret the audio information, are ignored by plugins (except Audition which uses them), and do not restrict the format in any way. A similar mechanism could be added to FLAC so that it too could, if desired, make perfect copies of wav files. Certainly this would not hobble the format or detract in any way; it would simply be an additional feature. (I am, of course, not suggesting this be added to FLAC. Given the enormous popularity of FLAC, I need every niche I can find! )
It would have been nice if I had set up wvunpack to create a basic wav header if there wasn't one in the WavPack file, but I didn't. So now all WavPack files must contain at least a 44 byte wav header because I think it would be silly to break old wvunpack versions to save 44 bytes, and the encoding library now transparently generates this if the application does not supply it.
While it is correct that in a perfect world I would interpret all the RIFF subchunks and convert them into some internal representation, this is simply not tenable. First, there are simply too many different ones to handle, new subchunk types are constantly being added, and some people have simply defined their own. Also, in some cases, converting back to RIFF might not be lossless because there is some flexibility in writing the subchunks (for example, the order or whether or not items are collected into a LIST chunk).
Obviously nobody would complain if an MP3 encoder discarded RIFF data. However, because archiving is one of their primary uses, I believe that lossless audio compressors are different. That extra RIFF information is part of the archive, and the fact that FLAC discards those unknown subchunks simply makes it unusable for some (albeit rare) applications. The fact that WavPack saves them does not similarly make it unusable for any current or future application (except maybe for the guy that specifically wanted them discarded, for whom I have now provided an option).
This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.[a href="index.php?act=findpost&pid=340767"][{POST_SNAPBACK}][/a]
Just a quick question: does the encoder support WV input? To recompress from one compression ratio to a higher one without decoding to wav first.
This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.[a href="index.php?act=findpost&pid=340767"][{POST_SNAPBACK}][/a]
Just a quick question: does the encoder support WV input? To recompress from one compression ratio to a higher one without decoding to wav first.
[a href="index.php?act=findpost&pid=340793"][{POST_SNAPBACK}][/a]
No, sorry, wavpack.exe does not accept WavPack files right now.
There are a couple ways around this. You can use pipes so that no intermediate wav file is created but you'll need to do one file at a time and you'll have to copy tags using another app.
A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.
A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.[a href="index.php?act=findpost&pid=340796"][{POST_SNAPBACK}][/a]
Another elegant solution would be dbpoweramp.
A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.[a href="index.php?act=findpost&pid=340796"][{POST_SNAPBACK}][/a]
Another elegant solution would be dbpoweramp.
[a href="index.php?act=findpost&pid=340812"][{POST_SNAPBACK}][/a]
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
A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.
[a href="index.php?act=findpost&pid=340796"][{POST_SNAPBACK}][/a]
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
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
[a href="index.php?act=findpost&pid=341329"][{POST_SNAPBACK}][/a]
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.
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.
[a href="index.php?act=findpost&pid=341342"][{POST_SNAPBACK}][/a]
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.
I don't think this option does exist... but I really like the idea.
[a href="index.php?act=findpost&pid=341578"][{POST_SNAPBACK}][/a]
OHHHHHHHHHHHYEAAAAA!!
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
[a href="index.php?act=findpost&pid=341566"][{POST_SNAPBACK}][/a]
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?
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?
[a href="index.php?act=findpost&pid=341590"][{POST_SNAPBACK}][/a]
the best thing for maximum compatibility (or ease of use for unexperienced users) would be if wvunpack would edit the line
FILE "Image.wav" WAVE
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
But would I have to parse it and change some filenames or paths?
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:
but this is not a must i think
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.
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.
[a href="index.php?act=findpost&pid=341595"][{POST_SNAPBACK}][/a]
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.
a command-line replaygain scanner[a href="index.php?act=findpost&pid=341336"][{POST_SNAPBACK}][/a]
Wonderful! The last piece falls into place.
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!
[a href="index.php?act=findpost&pid=341606"][{POST_SNAPBACK}][/a]
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)
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
...[a href="index.php?act=findpost&pid=341657"][{POST_SNAPBACK}][/a]
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
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
[a href="index.php?act=findpost&pid=341657"][{POST_SNAPBACK}][/a]
is there some setting that i missed? because afaict foobar _does_ care about the file line, 0.8.3 at least does.
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
[a href="index.php?act=findpost&pid=341657"][{POST_SNAPBACK}][/a]
is there some setting that i missed? because afaict foobar _does_ care about the file line, 0.8.3 at least does.
[a href="index.php?act=findpost&pid=341669"][{POST_SNAPBACK}][/a]
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 (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:
replaygain_track_gain = -5.22 dB
replaygain_track_peak = 0.977234
replaygain_album_gain = -4.93 dB
replaygain_album_peak = 0.977234
and here are foobar's on the same track:
replaygain_track_gain = -5.23 dB
replaygain_track_peak = 0.977233
replaygain_album_gain = -4.94 dB
replaygain_album_peak = 0.977233
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 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.
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.
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!!
Excellent. Thank-you very much, David
And before anyone asks, no, I am not going to add recursive scanning (at least not for a while).[a href="index.php?act=findpost&pid=341692"][{POST_SNAPBACK}][/a]
Well, people can easily work it out: on Windows with Case's Sweep, and on *nix with shell scripts.
...
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.
...[a href="index.php?act=findpost&pid=341720"][{POST_SNAPBACK}][/a]
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
The only thing I noticed is that the gain values are 1 number different than when foobar calculates the gain[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=341694")
There has been some changes to the wavegain source lately: [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=38290]Wavegain problems in Linux[/url].
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. =/
... your excelent TAG program.
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'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.
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 (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 ?
Hello!
Are there (important) differences between the 4.31 of Thanksgiving and the new 4.31 released yesterday ?
[a href="index.php?act=findpost&pid=350090"][{POST_SNAPBACK}][/a]
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
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[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362335")
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.
[a href="http://www.foobar2000.org/components.html#foo_wavpack]The one offered at foobar2000.org[/url] 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
The one offered at foobar2000.org (http://www.foobar2000.org/components.html#foo_wavpack) is version 2.0.b2
The one in the current foobar2000 0.8.3 special compile is 2.2 (IIRC...).
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 (http://www.wavpack.com/files/foo_wavpack.zip)
http://www.wavpack.com/files/foo_wavpack.zip (http://www.wavpack.com/files/foo_wavpack.zip)
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362436")
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 [a href="http://www.wavpack.com/wavpack-4.31.zip]http://www.wavpack.com/wavpack-4.31.zip[/url]
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=39674)
Sergio
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[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362335")
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.
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:
[a href="http://www.wavpack.com/files/foo_wavpack.zip]http://www.wavpack.com/files/foo_wavpack.zip[/url]
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..."