how to keep metadata from wav? (question)

[geextahslex]

Hi, this is not an issue, but I don't know about a forum or a place where I could ask this question. How can I keep the metadata from a wav file when using wavpack. I am using this command: wavpack -hh -x4 -m --threads input.wav When I use ffmpeg the metadata is still present in the wv file with: -c:a wavpack -compression_level 3 output.wv

Thanks for any help :)

edit: I have noticed that after decoding wv in wav with wvunpack the metadata reappears, is there a way to see it when the file is wv?

[dbry]

There is a dedicated WavPack forum here, but posting an issue right here works too (although I'm probably the only one who will see it).

I'm a little confused because normally I would think that the WavPack command-line programs would be better than FFmpeg for retaining metadata in WAV files. And, as you discovered, when you restore a WAV file using the command-line wvunpack program the original WAV file is always exactly restored (so obviously all metadata is back).

First of all, what metadata are we talking about? Is it like artist and title and stuff like that? Or is it loop and cue and technical metadata like that?

And so you claim that when you create WavPack files using FFmpeg something is retained that you can access afterward, but when you use the wavpack command-line program it doesn't show up. How is it that you try to view this metadata?

Another thing to try is to use the command-line wvunpack -ss file.wv to examine the two files. That will tell you exactly what metadata is in there and also the size of the stored WAV headers (which also can contain metadata). Comparing the output from each file should tell us exactly what's going on.

Hope this helps!

[geextahslex]

Thank you for your answer.

First of all, what metadata are we talking about? Is it like artist and title and stuff like that? Or is it loop and cue and technical metadata like that?

I am not talking about any fancy metadata, actually the basic stuff like Artist, Album, Title.

And so you claim that when you create WavPack files using FFmpeg something is retained that you can access afterward, but when you use the wavpack command-line program it doesn't show up. How is it that you try to view this metadata?

I use mediainfo og wav

ffmpeg wavpack, the metadata is slightly changed, kinda different arrangement but you can see it even in wv form

native wavpack, here its missing

Another thing to try is to use the command-line wvunpack -ss file.wv to examine the two files. That will tell you exactly what metadata is in there and also the size of the stored WAV headers (which also can contain metadata). Comparing the output from each file should tell us exactly what's going on.

This gave me these results. Yes they look pretty different.

ffmpeg wavpack

native wavpack

file wrapper and encoder version 4/5 are different

The downside is that if you would actually want to store everything with wavPack (without decoding back to wav) you would lose this information, I mean it's kinda there but "hidden"

[dbry]

Okay, I see what's happening. The metadata is stored in the RIFF header in the WAV file. That's kind of a non-standard way of storing them, but apparently FFmpeg knows about it. Where did these WAV files come from?

Anyway, if the metadata is in ID3 tags (possible) then you could add the --import-id3 to the wavpack encoder command-line and they would get picked up then. Otherwise the only way would be to use some third-party tagging utility like Mp3tag (which comes from your country I think).

If it's not too much trouble I would like to have one of these WAV files to check (maybe this is something I should support, even though I've never seen it before). You could compress a short track with WavPack using -b2 and it would get really small, and that would be fine (I just want the header). Thanks!

[geextahslex]

From music streaming providers, not sure which one, but it is originally a flac, I made the wav with ffmpeg because xiph flac CLI removes all metadata. Sure here it is. input.zip I already tried this command --import-id3 and it didn't work.

Awesome a fix for that in the future would be appreciated :) Already the new --thread option is a game changer. 4,5x faster on my system (quad core) It should be the default option. It boosts encode and decode, like mentioned in the latest release.

[dbry]

Cool, thanks for the file. I'll take a look.

And thanks for the comments about --threads. I have considered making it the default (and adding a --no-threads to disable), especially because it doesn't seem to slow down even single-core machines.

[geextahslex]

You welcome. Yes exactly and probably not everyone knows about it, and is missing out. It is also a strong argument against going with ffmpeg when you are into wavPack. I can understand leaving --optimize-int32 because of back compat, but it will also have be the default in the future.

[geextahslex]

Here is a native flac, maybe this helps somehow Flac.zip

[dbry]

Yes, thanks, the flac can help too. I also will probably just have to look into FFmpeg and see what it's doing with these tags to make sure I get them all.

[geextahslex]

As Im planing to switch all flac files to wavpack, how should I handle the metadata that is stored in the flac files? As you have to convert flac back to wav and then to WavPack. It would be nice to see the metadata in the wv files.

[dbry]

I think the best strategy would be to avoid converting through WAV altogether. WAV files don't really have a standard method of holding metadata, and some of the ad-hock methods that are used have severe limitations (like field length or character set availability).

I generally use Foobar2000 for trancoding because it handles WavPack great and is very good and preserving metadata (even cover art) and it uses the command-line program to encode. FFmpeg also does a good job (although at one point cover art was sometimes lost). If you don't like using the FFmpeg WavPack encoder, one thing that I often do is use the WavPack command-line program to reëncode the resulting files with the mode and features you want. This makes it a fresh file with no leftover FFmpeg-isms (except their encoder name which they add to the tags, but this can be deleted).

If you insist on going through WAV files, then using a tag editor like Mp3tag (mentioned above) to copy the tags afterward would work.

[geextahslex]

I'm fine without converting to wav, but does wavPack accept flac as input? I tried it and the cmd window closes. There is nothing wrong in using ffmpeg generally but I feel like the implementation of WavPack is not the best. It lacks the latest --threads option and from my understanding it's not the real libwavpack. Generally I wanted to use the native encoder. I never tried foobar2000

[dbry]

No, WavPack does not accept FLAC as input. You have to use something that decodes FLAC, like FFmpeg or Foobar2000.

FFmpeg uses their own implementation of WavPack for both encoding and decoding. It does not generate the latest version of the format (version 4 instead of 5 as you discovered above) but that's not really a big deal. They're lossless and the audio is correct, but you're right that they don't support multithreading for encode. But that's why I suggested using the default mode in FFmpeg for a quick-and-dirty conversion and then reëncoding in place using the command-line program. You can use --threads and whatever mode you'd like and the results are fully modern version 5.

Foobar2000 uses the WavPack command-line program for encoding and has libwavpack internal for decode, so no such issues there. And you can specify any options you want in the conversion configuration dialogs.

[geextahslex]

I also will probably just have to look into FFmpeg and see what it's doing with these tags to make sure I get them all.

Okay I just hope that in future the metadata can be transfered from the source wav (like ffmpeg), that would be a bit more straightforward ^^'