1) WavPack uses APEv2 tag format and it comes to the end of file. In some other posts FLAC developer said: "there are disadvantages to tags being at the end which is why it's not done that way in FLAC or vorbis". My question is what are these disavantages and advantages with a tag being at the end OR at the beginning?

2) Is it exceptionally depending on K3B developers for them to support WavPack out of the box, or a plugin could be written? (Aside from being supported with ffmpeg option in compilation).

3) Is it exceptioally depending on Audacity developers for them to support WavPack, too?

4) I've seen Totem crash after playing a WavPack file entirely, what is the cause of this?

5) Can we expect the 1MB tag limitation for binary tag to be overcome in next releases?

6) Can we expect recoding from already encoded WavPack files in next releases?

1) WavPack uses APEv2 tag format and it comes to the end of file. In some other posts FLAC developer said: "there are disadvantages to tags being at the end which is why it's not done that way in FLAC or vorbis". My question is what are these disavantages and advantages with a tag being at the end OR at the beginning?

I'm sure this general topic has been covered many times. Basically.

* Tags at the end allow for easier metadata modification. If the metadata area has to "grow", you don't have to rewrite the entire file. This isn't too big of a deal for MP3, but with lossless files, the filesize is large enough for the performance impact to be noticeable.

* Tags at the beginning of the file are much easier for streaming scenarios. Tags at the end of the file require that a seek be made to the end of the file to get the tag length, a subsequent seek to be made to go the start position of the metadata. This isn't a big deal for local files, but requires three additional HTTP connections to be made in a streaming scenario (seeking in HTTP is accomplished by disconnecting and re-connecting with a new Range Request header). One initial connection (possibly a HEAD request) to get the content length. One connection to read the last 4 bytes or however much data must be read to determine tag size, and one last connection to to read the metadata. followed of course by a connection back to the beginning for playback.

Thanks, Ben...your answer is far better than what I would have come up with!

I have not looked into K3bís source code, so Iím not sure exactly what they mean by a ďpluginĒ, but since itís open-source it would be easy for an experienced developer to add WavPack support (it would not have to be them).

The situation with Audacity is pretty much the same as K3b. In fact, I would really appreciate someone taking on the project of putting good WavPack support in there because itís requested often and itís something that I would use myself (I use CoolEdit on Windows, which is not too handy because I do most development on Linux).

I have not seen this crash, but I do not play WavPack files in Totem too often. My guess is thatís a bug in the gstreamer stuff or in Totem.

My feeling is that 1 MB is a reasonable limit for tag attachments. The purpose is to store smaller jpegs for album art display on music players, not high-res originals for archiving. Large tags can cause trouble for embedded player implementations with respect to both memory use and latency times. I would recommend that large items be stored as separate files.

I have not decided much about the next release, but this is one of the features I will look at. If I can do it cleanly in a few days Iíll put it in, but if some part of it becomes nasty then I wonít.

Just wanted to know how to make K3B support WavPack on Fedora 14, because, somehow the compilation now is:mkdir buildcd buildcmake .. (I guess this is to replace "configure" options, but you can't configure anything really)make install