Musepack Forums  

Go Back   Musepack Forums > Main > General

Reply
 
Thread Tools Search this Thread Display Modes
Old 26 July 2009, 06:39 am   #1
Goweropolis
Member
 
Join Date: Jan 2005
Posts: 10
Arrow Help me get SV8 supported in Squeezebox

Hi guys,

I have a Logitech Squeezebox and I have submitted a request to have them support SV8. I need some help though because they're telling me that the options for the new "mpcdec" have changed compared to the old SV7 decoder "mppdec". Is that true?

The bug was filed here, so if someone could respond here or there with some helpful tips, that'd be great. I just want to make sure that I answering the technical questions correctly, so it gets implemented quicker.

Thanks.

Last edited by Goweropolis; 30 July 2009 at 03:54 pm. Reason: fixed spelling
Goweropolis is offline   Reply With Quote
Old 26 July 2009, 11:28 am   #2
Shy
Admin
 
Shy's Avatar
 
Join Date: Jul 2004
Posts: 372
Default

Hi.

Does SqueezeCenter seriously not have its own decoders? I didn't think it's an application that uses external command-line decoders for audio file playback..

mpcdec is just a decoder sample application, meant to do nothing more than decoding. mppdec was a an actual player as well (which is very uncommon and should not even be expected from a usual command-line decoder)

Conversion to various formats, sample rates and bit depths, tag reading, ReplayGain, etc. should be handled by the player or streamer application itself, not third-party command-line decoders. By the way, their default of applying title-based ReplayGain is a bad choice, especially for albums with continuous tracks.

If they must have the mppdec features, they could keep using it for SV7 files and for SV8 files they could use mpcdec. But in case the program can't even read file headers and detect that it's an SV8 file, then they couldn't.
Shy is offline   Reply With Quote
Old 26 July 2009, 09:56 pm   #3
Goweropolis
Member
 
Join Date: Jan 2005
Posts: 10
Default

Yes, they don't decode MPC natively. I think only FLAC, Vorbis, WMA, and good 'ol MP3. Not sure why they don't use a "streamer application" as you put it. I think the big issue is they need to change the audio stream to a format that their hardware player can decode; which is why they are transcoding from MPC to FLAC or MP3 for actual network transmission to the player itself.

Somehow I think they won't want to use two different decoders which depend on the stream version.

Would the same command lines they're using for decoding "mppdec" work the same when using "mpcdec"? If so, then they shouldn't have to change their configuration. All they need to figure out is how to decode MPCs through the command line using the new "mpcdec" and it should work.

Last edited by Goweropolis; 30 July 2009 at 03:54 pm. Reason: fixed spelling
Goweropolis is offline   Reply With Quote
Old 27 July 2009, 04:19 pm   #4
Shy
Admin
 
Shy's Avatar
 
Join Date: Jul 2004
Posts: 372
Default

The command lines mentioned on that page are only valid for mppdec. mpcdec just decodes to wav and without replaygain.
Shy is offline   Reply With Quote
Old 27 July 2009, 05:25 pm   #5
Goweropolis
Member
 
Join Date: Jan 2005
Posts: 10
Default

How should I suggest that they handle this issue? Do they need to avoid the command line decoder and use some other method? I'm no technical/programming expert, I am just trying to get SV8 supported, but I'm not really sure how to proceed.
Goweropolis is offline   Reply With Quote
Old 30 July 2009, 05:29 pm   #6
Shy
Admin
 
Shy's Avatar
 
Join Date: Jul 2004
Posts: 372
Default

The method used by almost all software developers is to create their own decoder based on the available Musepack decoder library (or "source code") or on a third-party decoder library (such as GStreamer or ffmpeg). The decoder is either included within the application itself or provided as a plugin.

I think any developer would agree that using someone else's command-line deocder is not a recommended method for playback or streaming and can't be expected to be reliable or work at all.

In short, I don't know whether it's a possibility for them or not, but my suggestion would be that they take the usual, widely-accepted and expected approach, and based on the source code create their own decoder which can have any features they need and leave out any features they don't.

I wish people didn't advertise that a product "supports" a format when in fact it just uses a third-party application to do the work for them in a dirty way. But there's really nothing we can do about it.. I appreciate your efforts and understand your frustration. Hopefully this issue could be fixed and you could enjoy your audio and not have to mess around with compatibility issues.
Shy is offline   Reply With Quote
Old 30 July 2009, 06:43 pm   #7
andyslim
Member
 
Join Date: Jul 2009
Posts: 4
Default

Quote:
Originally Posted by Shy View Post
Conversion to various formats, sample rates and bit depths, tag reading, ReplayGain, etc. should be handled by the player or streamer application itself, not third-party command-line decoders. By the way, their default of applying title-based ReplayGain is a bad choice, especially for albums with continuous tracks.
Just wanted to respond to this. Absolutely agree, transcoding, tag reading, resampling, RG, should not be handled by the command-line decoder. It should only output raw data. And we have perfectly fine replay gain support, that applies album gain when playing sequential tracks from an album, and track gain when not, as you'd expect.
andyslim is offline   Reply With Quote
Old 30 July 2009, 10:09 pm   #8
Shy
Admin
 
Shy's Avatar
 
Join Date: Jul 2004
Posts: 372
Default

Hi Andy.

mpcdec.c which is included in our source code (/libmpc/trunk/mpcdec/) could be modified and any needed feature could be added. Building a modified decoder is then a simple matter. But using very simple command-line decoders in an entire framework is very risky in many ways and I wouldn't recommend it.

We may add raw output and other features to mpcdec in the future, but that probably won't be very soon as our main developer has been busy lately. You could add it yourself in the meantime, though, but still I'll say that mpcdec as it is, is a very simple application just meant to decode files for our users, and quite unsuitable to be a part of a framework.

Thanks for the response.
Shy is offline   Reply With Quote
Old 30 July 2009, 10:30 pm   #9
andyslim
Member
 
Join Date: Jul 2009
Posts: 4
Default

I disagree, there is nothing wrong with using command-line decoders. It's only risky if the decoder is buggy. We've been using this method for years and it's very flexible. You would have to understand our architecture I guess...

Anyway, I guess it's a tradeoff between SV8 support and dropping support for PCM output. We have very few MPC users anyway so SV8 will probably win.
andyslim is offline   Reply With Quote
Old 30 July 2009, 10:35 pm   #10
Shy
Admin
 
Shy's Avatar
 
Join Date: Jul 2004
Posts: 372
Default

You mean people actually prefer to stream raw pcm instead of flac? I don't guess anyone would cry if PCM was dropped.
Shy is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 06:21 am.


Powered by vBulletin® Version 3.8.11 Beta 2
Copyright ©2000 - 2020, vBulletin Solutions Inc.