Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WavPack 5.0.0 Final Release (Read 51604 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: WavPack 5.0.0 Final Release

Reply #50
Today Qaac released the 1.6.2 ver and support for the wavpack-dsd decode as pcm ,
so now I can use qaac to convert wv-dsd to aac file.
But tags missing occuered.
I wonder some information for Qaac's developer to solve this problem.
Doesn's wavpack-dsd use apev2 tags ?
Well, seems if we convert a tagged dsf to wavpack-dsd.
wavpack doesn't convert the tag to apev2 and just store the original tag for restoring.
So I think the last foo_input_sacd and qaac doesn't reconnize the tag is correct.
Seems after converting to  wavpack-dsd I need to retag all of them once.
Can wavpack make an option to convert the original dsf tag to apev2 type automatically?

Re: WavPack 5.0.0 Final Release

Reply #51
What exactly does wavpack omit when using fast instead of high mode? I can't seem to hear a difference on the lossy part, but manual states that there is a negative effect on lossy quality in fast mode. Is it only really showing on low bitrates?

Re: WavPack 5.0.0 Final Release

Reply #52
Can wavpack make an option to convert the original dsf tag to apev2 type automatically?
Yes, this is something I did not get a chance to look into before. As you know, DSF files can have ID3 tags at the end, and WavPack saves these as the audio data “wrapper” so that the original file can be restored by wvunpack. You can actually see the presence and size of this tag by using the -ss option of wvunpack. Some of the DSF files I have obtained have as much as 3 MB of information in those tags (photos and scans mostly I assume, but I never looked).

It is possible for apps using libwavpack to obtain this info, but it can't be edited.

As you say, it should be possible to translate this to APEv2 tags, although I'm not sure that that would be completely unambiguous. Does anyone know how easy this would be offhand? It seems to me there were many versions and parsing complications with ID3 tags.

Re: WavPack 5.0.0 Final Release

Reply #53
What exactly does wavpack omit when using fast instead of high mode? I can't seem to hear a difference on the lossy part, but manual states that there is a negative effect on lossy quality in fast mode. Is it only really showing on low bitrates?
Basically, switching from “high” to “fast” is going to increase the noise a little and hurt the compression a little. You can use the -n option to see this, and I just measured 3 dB higher noise and about 1% worse compression. Of course, by changing the bitrate you can shift the cost around. So, for example, by increasing the bitrate here by 100 kbps you can reduce the noise back down so that the “fast” mode will have the quality as “high”.

I am not surprised that you could not hear a difference. At these bitrates the noise will normally be way below even the noise floor of the recording. Here's a spectrum of the signal (cyan) and added noise (magenta) for a 24/96 recording (NIN) encoded at 1024 kbps (don't remember the mode, probably “high”). Especially since it's shifted up in frequency, that noise is not going to be audible even without the masking effect of the source audio!



This is why I've always advocated WavPack lossy as a potentially efficient format for high-resolution recordings. I suspect that part of the reason this has not caught on is that the audience that might be receptive to it is so limited. Subjectivists are skeptical of anything lossy regardless of the technical arguments for it (and perhaps, even if they tried it, hesitant to admit that it sounds the same). On the other hand, objectivists will immediately convert any high-resolution recordings they come across to 16/44.

Re: WavPack 5.0.0 Final Release

Reply #54
Thank you David for the new version & continued development.

Re: WavPack 5.0.0 Final Release

Reply #55
Well, I ended up going with -b384fcx6, since I can't hear the difference anyway, and the slightly lower compression ratio doesn't bother me. I guess once some people read that -f adds noise, they just jump to -h without testing.

Subjectivists are skeptical of anything lossy regardless of the technical arguments for it (and perhaps, even if they tried it, hesitant to admit that it sounds the same). On the other hand, objectivists will immediately convert any high-resolution recordings they come across to 16/44.
I'd do the latter too, except I like to keep the original files untouched - simply because they're original. Now, if there was an option to have the lossy part as 16/44 with the correction file restoring the original bit/sampling rate.... though I think that would blow up the combined filesize a lot, kind of like keeping a too low bitrate for high res did for me.


Re: WavPack 5.0.0 Final Release

Reply #57
Thanks you David for the new tool, though I finished retaging for all wv-dsd.

I would like to ask one more help.

Now I want to convert all my thounds flac files to wavpack .
And I want the tag from flac.
Using Foobar200 can do it but I notice that if I use foobar2000, the output wavpack file is a little bigger than using command-line in same setting.
I don't know why but I want to keep the file smallest so I decide to use command-line.
But for using command-line I can't copy tags from flac to wavpack.
Would you please to make wavpack.exe easily using like qaac can use the external library for converting from flac than can transfer the tag or make WVTAG can simply do
wvtag input.flac output.wv
to copytag into APEv2 and store to wv?
Thanks a lot.

 

Re: WavPack 5.0.0 Final Release

Reply #58
Thanks you David for the new tool, though I finished retaging for all wv-dsd.

I would like to ask one more help.

Now I want to convert all my thounds flac files to wavpack .
And I want the tag from flac.
Using Foobar200 can do it but I notice that if I use foobar2000, the output wavpack file is a little bigger than using command-line in same setting.
I don't know why but I want to keep the file smallest so I decide to use command-line.
But for using command-line I can't copy tags from flac to wavpack.
Would you please to make wavpack.exe easily using like qaac can use the external library for converting from flac than can transfer the tag or make WVTAG can simply do
wvtag input.flac output.wv
to copytag into APEv2 and store to wv?
Thanks a lot.
The results from foobar2000 and the command-line should be the same. If there is a size difference the tags may be responsible for that. Even then, the difference in size should be minimal unless you are placing cover-art in tags. Finally, once you have copied the tags to the wavpack files, the size should end up being the same. I'd just go with foobar2000 since it's more convenient.

Re: WavPack 5.0.0 Final Release

Reply #59
Thanks you David for the new tool, though I finished retaging for all wv-dsd.

I would like to ask one more help.

Now I want to convert all my thounds flac files to wavpack .
And I want the tag from flac.
Using Foobar200 can do it but I notice that if I use foobar2000, the output wavpack file is a little bigger than using command-line in same setting.
I don't know why but I want to keep the file smallest so I decide to use command-line.
But for using command-line I can't copy tags from flac to wavpack.
Would you please to make wavpack.exe easily using like qaac can use the external library for converting from flac than can transfer the tag or make WVTAG can simply do
wvtag input.flac output.wv
to copytag into APEv2 and store to wv?
Thanks a lot.
The results from foobar2000 and the command-line should be the same. If there is a size difference the tags may be responsible for that. Even then, the difference in size should be minimal unless you are placing cover-art in tags. Finally, once you have copied the tags to the wavpack files, the size should end up being the same. I'd just go with foobar2000 since it's more convenient.

NO,even no any tags. The size is not the same . So,I am very confused.
I will update some resaults here later if I have free time today.

Re: WavPack 5.0.0 Final Release

Reply #60
Do some compare using Foobar2000 AND command to encode wavpack
Both I use the same wavpack 5.0 x64 encoder and same setting which should make same resault normally.

test.WAV( without Any Tag)
size:399 MB (418,387,916 bytes)

Use foobar2000: use : -i -q -hh -x6 -m - %d
size:178 MB (187,597,128 bytes)

Use comman-line:wavpack -hhx6 -m test.wav
size:178 MB (187,587,640 bytes)


So why? Is it a bug in Foobar2000 on Encoding Wavpack or not?
Because I tried the same thing before on Flac it make the same size on output files.

Re: WavPack 5.0.0 Final Release

Reply #61
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d

Re: WavPack 5.0.0 Final Release

Reply #62
So why? Is it a bug in Foobar2000 on Encoding Wavpack or not?
Because I tried the same thing before on Flac it make the same size on output files.
I would suggest using the command-line wvunpack with -ss to compare the output files. First you can see if the audio MD5s actually match (perhaps there's audio processing being done?) and you can also check if there's an invisible tag added (or anything different, actually).

As for importing FLAC tags in WavPack, I can see why that would handy, but it's really beyond the scope of what I think belongs in WavPack. I would have to include or link to libflac somehow, which could cause problems, or write my own parser, which I think would be a big project. For ID3v2 I wrote my own parser in a few days because it's a standard part of the DSF format, but I'm still worried that tags will come along that break it (I didn't implement anything that I didn't have a sample file for).


Re: WavPack 5.0.0 Final Release

Reply #64
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d
That's funny! I wondered why you suggested this because I didn't think that using pipes (and the -i option) should make a difference.

Anyway, it obviously does and I figured out why, and it's definitely not intended behavior. It will be fixed next release.

Thanks for pointing this out, but I have a question. How did you know this was going to do that?  :)

Re: WavPack 5.0.0 Final Release

Reply #65
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d
That's funny! I wondered why you suggested this because I didn't think that using pipes (and the -i option) should make a difference.

Anyway, it obviously does and I figured out why, and it's definitely not intended behavior. It will be fixed next release.

Thanks for pointing this out, but I have a question. How did you know this was going to do that?  :)

Hello David, would it be long for this realse ? 
Thanks !

Re: WavPack 5.0.0 Final Release

Reply #66
How did you know this was going to do that?  :)
I thought that wavpack reserves some space for seektable or something like this (and reserves more space if wave length is unknown)

Re: WavPack 5.0.0 Final Release

Reply #67
Ah, that makes sense, maybe FLAC does something like that too?

But no, WavPack does not have seektables and there shouldn't be any difference between the various options. But the “ignore length” option (and some others) were accidentally triggering the write of a redundant status word, so every block was 2 bytes longer than it should have been. No ill effect, but not as intended.

Samidare1234, maybe a week or two for the next release.

Re: WavPack 5.0.0 Final Release

Reply #68
Just dropping this here, since I don't want to specifically make a new thread about it: I just finished converting my library from TAK to WV hybrid. The overall increase in space usage is 6.78% with -b384fx6 (302.522GiB tak -> 323.039GiB wv+c)

This is about what I expected, it was about the size of my library in FLAC before moving to TAK, plus a slight increase from using hybrid. Overall, I'm satisfied - I could probably push the size down by switching to -h, but I'd die of old age at those de-/encoding speeds. I wonder what black magic TAK uses to reach such compression levels and still maintain high de-/encoding speeds. Though this speed is offset by abysmal support, which pushed me to abandon it.

Wavpack on the other hand is well supported on all platforms I use, so thank you, bryant, for developing this codec!

Re: WavPack 5.0.0 Final Release

Reply #69
I'm glad WavPack is working our for you...it's always nice to hear someone finds it useful!

BTW, this won't affect your encodings, but the new version (5.1.0) should be released in just a few days.

Re: WavPack 5.0.0 Final Release

Reply #70
As promised, WavPack 5.1.0 is released. It's available in the same place as always.

Compared to 5.0.0, this is a minor update, but has a few fixes and improvements:

  • added: all new command-line tagging utility (wvtag)
  • added: option to import ID3v2.3 tags from Sony DSF files
  • fixed: fuzz test failures from AFL reported on SourceForge
  • improved: DSD decimation filter (less HF rolloff & CPU use)
  • fixed: non-byte audio depths (12-bit, 20-bit) not showing
  • fixed: rare case of noise-shaping triggering a lossy mute
  • fixed: recognize UTF-8 BOM when reading text files
  • fixed: a few portability issues

Many thanks to all HA members who contributed to this by incorporating WavPack into their projects, with testing and suggestions, and of course by just using WavPack; it is all greatly appreciated!  :)

Re: WavPack 5.0.0 Final Release

Reply #71
Thanks David! Does this new version change any filesize on lossless files and dsd files?
I mean if I want smallest file do I need to re-encode to WavPack 5.1 ?

Re: WavPack 5.0.0 Final Release

Reply #72
I left it off the list, but yes, I fixed the issue you found where the -i option was causing an extra (unneeded) 2 bytes per block. Now the file sizes should always be the same with the same settings.

And that's the only file size change I made, so you should not need to re-encode, assuming you used the settings that lvqcl suggested. Thanks again to both of you for finding that!

Re: WavPack 5.0.0 Final Release

Reply #73
  • added: all new command-line tagging utility (wvtag)
Thank you for this, I used to manually compile apetag just to edit WavPack files in my scripts.
Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

Re: WavPack 5.0.0 Final Release

Reply #74
How to split dsd wv file with cue file?