Skip to main content ↑ ↓
Topic: WavPack 4.0 Beta Release 3 (Read 33030 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.0 Beta Release 3

Reply #25 –
Quote
Hmm, yes wavpack "*.wav" does work. But what's the difference? (or where can I read about that?)

The difference is that in the first case the shell resolve the wildcard and then passes all the matching files to the program. In the second case it passes the wildcard to the program. The wavpack command-line apps only support the later.

I can't test your script from here. But at least you should replace /bin/bash by /bin/sh. On most systems it's the same, but it's cleaner this way.

WavPack 4.0 Beta Release 3

Reply #26 –
Quote
One small thingy: in line 78 of wavpack.c you removed the '\n' at the end of the help text. This results in the prompt being on the same line as the last line of the help text in Linux.

Yeah, I removed the newline so that the whole display would fit on a DOS screen, even though it gets a little ugly. I think we can just send another newline in Linux.

I don't know what I'm going to do when I add more switches... 

WavPack 4.0 Beta Release 3

Reply #27 –
Quote
I don't know what I'm going to do when I add more switches... 

Use pause inbetween screens, just like ARJ did

WavPack 4.0 Beta Release 3

Reply #28 –
Quote
Quote
Hmm, yes wavpack "*.wav" does work. But what's the difference? (or where can I read about that?)

The difference is that in the first case the shell resolve the wildcard and then passes all the matching files to the program. In the second case it passes the wildcard to the program. The wavpack command-line apps only support the later.

Well behaved unix applications should never try to expand their own wildcard arguments.  They should just process whatever they're passed as arguments by their parent shell.  Luckily doing the right thing here is actually a lot easier than trying to write your own shell expansion code.

WavPack 4.0 Beta Release 3

Reply #29 –
I agree, but in the other hand the apps need a bit of intelligence to know that for a given file the .wvc file should be used (for example).

WavPack 4.0 Beta Release 3

Reply #31 –
Quote
The latest source code with a fix for MD5 on OS X and some minor fixes.

This compiles cleanly on my debian linux box.  Thanks!

Bryant - is there any chance you could add a seek function to wvunpack?  I rip cds to single flacs now and use flac's seek function to extract individual tracks from the resulting file.  I can't do this with wvunpack.

WavPack 4.0 Beta Release 3

Reply #32 –
It would also be nice if wavpack showed what x-level is used when using the -x option without giving an explicit number, and a higher resolution "progress meter"; maybe add one digit and a comma?    (looks nicer when doing slow encodings imho)

WavPack 4.0 Beta Release 3

Reply #33 –
Oh and another thing; when i rip an album to a single file + cuesheet, encode it to, say, 400kbps wavpack lossy, add the cuesheet as a tag and replaygain the tracks when opened in foobar2000.... where and how is the replaygain info stored?

WavPack 4.0 Beta Release 3

Reply #34 –
Quote
Oh and another thing; when i rip an album to a single file + cuesheet, encode it to, say, 400kbps wavpack lossy, add the cuesheet as a tag and replaygain the tracks when opened in foobar2000.... where and how is the replaygain info stored?

ReplayGain values are stored inside the cuesheet tag as REM comments.

WavPack 4.0 Beta Release 3

Reply #35 –
For those who might be interested I have created a new wvselfx.exe stub for WavPack 4.0 so that someone can now create (by hand) self-extracting WavPack files. Just use the DOS copy command to prepend this file to any WavPack 4.0 .wv file and it will become a self-extracting archive for any win32 machine:

Code: [Select]
copy/b wvselfx.exe+music.wav music.exe


I'll put the -e option back into wavpack.exe before the release. An nice improvement over the previous versions of this is that you can rename the resulting .exe back to .wv and it will be a perfectly fine WavPack file again (there can be up to 1 meg of garbage before the first WavPack block in a file).

http://wavpack.com/wvselfx.zip

BTW, I won't be releasing the source for this stub because it's a big mess. 

WavPack 4.0 Beta Release 3

Reply #36 –
Seems I can't decode files using absolute path, starting with slash, eg
Quote
wvunpack /mnt/c/wv/pj\ harvey/uh\ huh\ her/uh\ huh\ her.wv - | aplay

will result in
Quote
illegal option: n !
illegal option: t !
illegal option: / !
illegal option: c !
illegal option: / !
illegal option: w !
illegal option: v !
<snip>
illegal option: w !
can't delete in verify mode!
aplay: playback:1878: read error

Symlink (wvunpack uh\ huh\ her.wv) or relative path (wvunpack ../../../../mnt/ ...) will work otoh.

WavPack 4.0 Beta Release 3

Reply #37 –
Quote
Seems I can't decode files using absolute path, starting with slash, eg
Quote
wvunpack /mnt/c/wv/pj\ harvey/uh\ huh\ her/uh\ huh\ her.wv - | aplay

will result in
Quote
illegal option: n !
illegal option: t !
illegal option: / !
illegal option: c !
illegal option: / !
illegal option: w !
illegal option: v !
<snip>
illegal option: w !
can't delete in verify mode!
aplay: playback:1878: read error

Symlink (wvunpack uh\ huh\ her.wv) or relative path (wvunpack ../../../../mnt/ ...) will work otoh.

Yes, this will be fixed right away. The problem is that I had "/" in there as a very old option introducer, but this will go away for Linux. Thanks...

WavPack 4.0 Beta Release 3

Reply #38 –
Hmm. I should have just fixed it, then posted.

Here are the source fixes for that and the other problem Speek found:

http://wavpack.com/wp_options.zip

WavPack 4.0 Beta Release 3

Reply #39 –
David, where is our library  !

Toff and Mosu have TTA support and filters more or less finished, they would look at wavpack now  ....

WavPack 4.0 Beta Release 3

Reply #40 –
A few files have been updated. First, I found a bug in the CoolEdit / Audition filter that would cause an error when storing 20-bit or 24-bit files. The resulting files will still load fine in Audition and can be played fine, but if they are converted to wavs the RIFF header will indicate the wrong amount of data and there could be trouble. I have uploaded a new version in beta3.zip (see link at top of thread). To fix eny existing file (after updating the filter) simply load and re-save them in Audition. Sorry I didn't catch this in testing. 

Also, I found a problem introduced into the Linux source (does not affect the original Win32 source or beta executables). This could cause the command-line programs to crash on termination, but shouldn't cause any corrupted files to be written. Get the updated files here:

http://wavpack.com/wp_options.zip

Quote
Bryant - is there any chance you could add a seek function to wvunpack? I rip cds to single flacs now and use flac's seek function to extract individual tracks from the resulting file. I can't do this with wvunpack.
That is a nice feature of FLAC. I'll look into puting something like that in. (What would be nice is if could use the cuesheet and just decompress by track number...)

Quote
It would also be nice if wavpack showed what x-level is used when using the -x option without giving an explicit number, and a higher resolution "progress meter"; maybe add one digit and a comma?  (looks nicer when doing slow encodings imho)
The problem is that the X mode can take several seconds to work on a single block and I can't update the progress during that without a lot of trouble. So, even if I put in tenths of a percent it would still update slowly.

BTW, the X mode default is always X6 for fast mode, X4 for the normal mode and X3 for the high mode.

edit: added detail to clarify problem

WavPack 4.0 Beta Release 3

Reply #41 –
Quote
Quote
Bryant - is there any chance you could add a seek function to wvunpack? I rip cds to single flacs now and use flac's seek function to extract individual tracks from the resulting file. I can't do this with wvunpack.
That is a nice feature of FLAC. I'll look into puting something like that in. (What would be nice is if could use the cuesheet and just decompress by track number...)


Automatically splitting from cuesheets would be excellent!  One vote from me!

WavPack 4.0 Beta Release 3

Reply #42 –
Quote
Quote
[That is a nice feature of FLAC. I'll look into puting something like that in. (What would be nice is if could use the cuesheet and just decompress by track number...)
Automatically splitting from cuesheets would be excellent!  One vote from me!
[a href="index.php?act=findpost&pid=224482"][{POST_SNAPBACK}][/a]
... if we had this in matroska, the feature could be used for any supported audio format .... soon also for wavpack  ....

WavPack 4.0 Beta Release 3

Reply #43 –
Quote
The problem is that the X mode can take several seconds to work on a single block and I can't update the progress during that without a lot of trouble. So, even if I put in tenths of a percent it would still update slowly. sad.gif

BTW, the X mode default is always X6 for fast mode, X4 for the normal mode and X3 for the high mode.


I see. Well, thanks for the clarification anyways. Thanks for a great product.  Any idea when v4.0 will go final, and what's left to do before it does?

WavPack 4.0 Beta Release 3

Reply #44 –
I have created a tiny version of the WavPack 4.0 decoder for possible use in "resource limited" CPU devices (Palm, Pocket PC, ...?) or as the basis for hardware implementation. It uses less than 32k of code space, less than 4k of data space and does not require floating-point math. I included a demo that accepts WavPack files on stdin and outputs wav files to stdout.

http://wavpack.com/tiny_decoder.zip

Quote
Thanks for a great product.  Any idea when v4.0 will go final, and what's left to do before it does?
[a href="index.php?act=findpost&pid=224515"][{POST_SNAPBACK}][/a]

Thanks.  This was the first thing I wanted to complete. All that is left is to add reader callbacks to the regular library (I have decided to do that sooner rather than later) and update all the user documentation. There are no functional changes planned for the release, which should (assuming no surprises) be in the 1-2 week time frame.

WavPack 4.0 Beta Release 3

Reply #45 –
Quote
I have created a tiny version of the WavPack 4.0 decoder for possible use in "resource limited" CPU devices (Palm, Pocket PC, ...?) or as the basis for hardware implementation. It uses less than 32k of code space, less than 4k of data space and does not require floating-point math. I included a demo that accepts WavPack files on stdin and outputs wav files to stdout.

http://wavpack.com/tiny_decoder.zip


Wow !!! Very nice !
Does it support hybrid mode ? (with and without the complement file)
If so you should send it to all portable player makers (starting from iRiver by which I plan to buy the H-340) ! Then I could use WavPack everywhere

WavPack 4.0 Beta Release 3

Reply #46 –
[BUG] WavPack 4.0b3 Cannot Handle Double-byte Characters Properly

Hi,

I might be wrong, but I believe this is a bug in WavPack.exe:

[ Phenomenon ]
- It cannot handle 0x5c at the 2nd byte of a double-byte character properly.
WavPack will mistake it as the path separator (Backslash),
and will try to look for the file to encode in a wrong path,
confused by that pseudo path separator, and will complain "Can't open file FOO!"

[ Example ]
For instance, in my locale, Japanese, there is a character which would look like -\ in the ASCII code page, but it is actually one letter, SHIFT_JIS [0x96][0x5c], or U+66B4.

Now, if you try
wavpack foo[0x96][0x5c]bar.wav
then, wavpack will say,
Can't open file foo[0x96][0x5c]foo[0x96][0x5c]bar.wav!

Wavpack is right,  it can't open file foo[0x96][0x5c]foo[0x96][0x5c]bar.wav!
because such a file does not exist, but I asked Wavpack to compress foo[0x96][0x5c]bar.wav which DOES exist.

Note that [0x96][0x5c] here stands for one double-byte char like i said before.

[ Demo ]
http://www.faireal.net/tmp/wv-problem.zip

[ Note ]
Actually, this same bug was first found in ttaenc 3.1, and I did the same testing in wavpack, and was embarrassed to learn that Wavpack has the same problem...
I hope this will be fixed in the final 4.0 release...

Except this small problem, Wavpack seems really great.
Keep up a good job

WavPack 4.0 Beta Release 3

Reply #47 –
If I may ask, what happened to the plans for fixing quality hybrid mode for 4.0?

WavPack 4.0 Beta Release 3

Reply #48 –
Quote
Wow !!! Very nice !
Does it support hybrid mode ? (with and without the complement file)
If so you should send it to all portable player makers (starting from iRiver by which I plan to buy the H-340) ! Then I could use WavPack everywhere

It supports hybrid mode, but not the correction files. The correction files are probably the most complicated part of WavPack decoding, and also the most difficult part to integrate into other applications. I doubt that many portable players would easily handle streaming two files at the same time as they would have to have lots of RAM to buffer the data or be seeking back and forth like crazy. This wouldn't apply to flash players, but I can't see wanting to put lossless audio on those because of the limited space. Of course I can always add stuff back later, but I wanted to start with something as simple as possible to not scare anyone away.

I will be sending this to the player makers (and iRiver is definitely on the list), but it would help alot if users (and potential users) did the same as well (and posted on their boards). They're not going to just take my word for it... 

Quote
Actually, this same bug was first found in ttaenc 3.1, and I did the same testing in wavpack, and was embarrassed to learn that Wavpack has the same problem...
I hope this will be fixed in the final 4.0 release...

Hmm. This is a tough one because your test files work fine here, and I was not able to find any directly applicable information on the Internet. Was the problem fixed in TTA? Maybe I could look at what they did. It probably won't help, but you might try putting the whole filename in quotes.

Can anyone else shed any light on this?

Quote
If I may ask, what happened to the plans for fixing quality hybrid mode for 4.0?

Ah yes, I remember something about a quality mode...

Basically I decided that I had to get something out or WavPack 4.0 was going to start sounding like vaporware and that was one feature that could easily become a quagmire. I could tackle float support and multichannel without outside help, but getting the quality mode right takes lots of outside help (my old ears and eaqual only catch so much).

So, I left in all the hooks and as much flexibility as I could think of and figured I would return to the quality mode when there was less pressure to get something out that people could use, and hopefully I will be able to get something nice without breaking decoders. In fact, if all goes well then breaking decoders won't even be an option.

WavPack 4.0 Beta Release 3

Reply #49 –
Quote
Quote
Actually, this same bug was first found in ttaenc 3.1, and I did the same testing in wavpack, and was embarrassed to learn that Wavpack has the same problem...
I hope this will be fixed in the final 4.0 release...

Hmm. This is a tough one because your test files work fine here, and I was not able to find any directly applicable information on the Internet. Was the problem fixed in TTA? Maybe I could look at what they did. It probably won't help, but you might try putting the whole filename in quotes.


The test file works because your Windows doesn't use multibyte character set for legacy ANSI programs and Zip packed the filename as ANSI and it uncompresses incorrectly for anyone but Japanese.
You can read all about multibyte programming on MSDN.
 
SimplePortal 1.0.0 RC1 © 2008-2019