Musepack SV8 beta is out

[Seed]

When it's ready to be released

We aren't going to discuss a specific date. Everyone has to be patient and test every feature of the current beta as much as they can.

[slomo]

Will libmpcenc be compiled as a shared library and be installed for the release? Or is this still considered unstable and for internal use by mppenc, etc only?

[slomo]

Originally Posted by slomo

Will libmpcenc be compiled as a shared library and be installed for the release? Or is this still considered unstable and for internal use by mppenc, etc only?

Also, mpcgain does not build because configure doesn't check for any installed replaygain/gain_analysis.h header (where should this come from?) or because this header is simply missing from SVN

[r2d]

Originally Posted by slomo

Will libmpcenc be compiled as a shared library and be installed for the release? Or is this still considered unstable and for internal use by mppenc, etc only?

libmpcenc / libmpcpsy will not be installed as shared library because there is no clear API, and part of the needed functions to encode to musepack are still in the mpcenc code.

Originally Posted by slomo

Also, mpcgain does not build because configure doesn't check for any installed replaygain/gain_analysis.h header (where should this come from?) or because this header is simply missing from SVN

Yes, configure doesn't check for libreplaygain. You need to build libreplaygain from the svn and add the "include" dir in the list of includes.

[slomo]

Originally Posted by r2d

libmpcenc / libmpcpsy will not be installed as shared library because there is no clear API, and part of the needed functions to encode to musepack are still in the mpcenc code.

Ok... do you plan to provide a library for encoding at a later stage?

Originally Posted by r2d

Yes, configure doesn't check for libreplaygain. You need to build libreplaygain from the svn and add the "include" dir in the list of includes.

Ok, next issue is that mpcchap needs the cuetools source... would be nice if all sources required are in SVN. cuetools doesn't build a library one can link to it seems.

[r2d]

Originally Posted by slomo

Ok... do you plan to provide a library for encoding at a later stage?

The plan was mainly to simplify hacking, so people interested in the psymodel can understand the code more easily. As a side effect there may be encoding libraries, but it's not for now I think.

Originally Posted by slomo

Ok, next issue is that mpcchap needs the cuetools source... would be nice if all sources required are in SVN. cuetools doesn't build a library one can link to it seems.

Sorry, I added the code since your last post
cuetools doesn't provide a shared library, but there is a static lib in the /lib directory. I'll try to link the svn repository to the cuetools one to be able to checkout everything at once.

[Antonski]

May we assume that the "Chapter-Tag Packet" has a beta-status now? Actually, how it is supposed to be used?

Edit: I mean, about chapter-tags, is there an analogy with another format? Are they used and by which application? Just curious.

~

[slomo]

Originally Posted by r2d

The plan was mainly to simplify hacking, so people interested in the psymodel can understand the code more easily. As a side effect there may be encoding libraries, but it's not for now I think.

Ok, if there were encoding libraries I would create a gstreamer encoding plugin


On another issue, is there a bugtracker where one can create bug reports? The trac only allows this for people with an account and there seems to be no way to create one...

Well, currently libmpcdec exports some symbols which probably shouldn't be exported:

Cnk
Cnk_len
Cnk_lost
Res_bit
_Huffman_MakeTree
_Huffman_PrintCodes
__Cc
__Dc
crc32
huff_init_lut
streaminfo_encoder_info
streaminfo_gain
streaminfo_read_header_sv7
streaminfo_read_header_sv8


These should probably get a "mpc_" prefix or should not be exported at all. The most critical one here is "crc32", if you use libmpcdec in an application that also uses zlib (which exports crc32 too, with a different signature) you're unable to decode sv8 files because stuff simply segfaults.

It might make sense to simply use a libtool symbol export regexp here:

libmpcdec_la_LDFLAGS = -export-symbols-regex '^mpc_.*$$'

[r2d]

Originally Posted by Antonski

May we assume that the "Chapter-Tag Packet" has a beta-status now? Actually, how it is supposed to be used?

Edit: I mean, about chapter-tags, is there an analogy with another format? Are they used and by which application? Just curious.
~

ATM no player supports it. I suppose they should display each chapter as a track, like cue files. I'll let it with the alpha status until it is implemented in a player.

Originally Posted by slomo

Ok, if there were encoding libraries I would create a gstreamer encoding plugin ~

Does the current decoding plugin handles sv8 ?
radscorpion seems to be working on the encoding lib.

Originally Posted by slomo

Well, currently libmpcdec exports some symbols which probably shouldn't be exported

This should be much better now. Thanks for pointing this out, I didn't know about the issue.

[slomo]

Originally Posted by r2d

Does the current decoding plugin handles sv8 ?.

Yes, I have a pending patch that I'll commit shortly to add support for the new libmpcdec API in the decoder plugin (SV8 files will magically work then ).

Originally Posted by r2d

This should be much better now. Thanks for pointing this out, I didn't know about the issue.

Looks good now IMHO


Another issue I found now, is that for example mplayer (and probably xine too) is using mpc_decoder_decode_frame() from the old API. The function still exists with the new API but the mpc_bits_reader type which is needed for this is not exported by any public header file.

It'd also like to use that API in the future for the gstreamer decoding plugin as with the mpc_demux_* API it's not exactly easy to add support for decoding musepack stream inside of container formats like matroska for example.

[r2d]

Originally Posted by slomo

Yes, I have a pending patch that I'll commit shortly to add support for the new libmpcdec API in the decoder plugin (SV8 files will magically work then ).

That's good

Originally Posted by slomo

Another issue I found now, is that for example mplayer (and probably xine too) is using mpc_decoder_decode_frame() from the old API. The function still exists with the new API but the mpc_bits_reader type which is needed for this is not exported by any public header file.

It'd also like to use that API in the future for the gstreamer decoding plugin as with the mpc_demux_* API it's not exactly easy to add support for decoding musepack stream inside of container formats like matroska for example.

I moved mpc_bits_reader definition in mpcdec.h, thanks for your help.

Nicolas

[slomo]

Originally Posted by r2d

That's good

...and committed

Originally Posted by r2d

I moved mpc_bits_reader definition in mpcdec.h, thanks for your help.

Great, thanks

Another thing I noticed is, that libreplaygain exports more symbols than what is shown as public API by the header file. Could you add the same visibility stuff as for libmpcdec to libreplaygain? Apart from that it would be nice if libreplaygain would get properly namespaced (i.e. prefixed) symbols. Stuff like AnalyzeSamples is a good candidate for causing conflicts later...

[r2d]

Originally Posted by slomo

Another thing I noticed is, that libreplaygain exports more symbols than what is shown as public API by the header file. Could you add the same visibility stuff as for libmpcdec to libreplaygain? Apart from that it would be nice if libreplaygain would get properly namespaced (i.e. prefixed) symbols. Stuff like AnalyzeSamples is a good candidate for causing conflicts later...

Ok, changed that too.

[xmixahlx]

i'm breaking out the cuetools lib from upstream, so look for a tarball in a bit, r2d.

[xmixahlx]

from cuetools in svn...

patches for mpcchap:
http://xmixahlx.dyndns.org/dev/cueto...xmixahlx.patch
http://xmixahlx.dyndns.org/dev/cueto...xmixahlx.patch

patch for cuetools:
http://xmixahlx.dyndns.org/dev/cueto...xmixahlx.patch

tarball for cuetools:
http://xmixahlx.dyndns.org/dev/cueto...00.orig.tar.gz

patch for debian:
http://xmixahlx.dyndns.org/dev/cueto...wares1.diff.gz


new debian packages for replaygain, cuetools and musepack are upped to rarewares/debian

r2d, perhaps we should host the cuetools source like replaygain...

also, cuetools from svn includes some important updates from the debian maintainer, so anyone NOT on debian should grab from svn anyways.

slomo, are you the official debian maintainer for sv8 packages?


later

[slomo]

Originally Posted by xmixahlx

slomo, are you the official debian maintainer for sv8 packages?

Yes... so in cuetools SVN a shared library is built? That's good, I've disabled mpcchap in the packages for now and will enable them again once the cuetools Debian package provides the library

[xmixahlx]

well... i grabbed cuetools from svn, patched, and made my own packages (shared lib + dev)

...and after patching SV8 from svn it builds & works fine.

just grab my patches, etc. from the previous post and it will all make sense.


later

[Antonski]

Would somebody compile the binaries from the latest code?
Once I've tried, but my files were significant bigger and slower.
I would like to play a bit with chapter utility, just curious.

[Seed]

There is an archive compiled by the latest GCC. It'll be shared sometime today.

[Antonski]

Great! Would you post the link, please?