Bugzilla – Bug 270
Option to disable or removal of FLAC -> MP3 default transcoding when streaming to wireless Squeezebox
Last modified: 2009-09-08 09:12:55 UTC
I have become convinced that this new behaviour is wrong. For example I want to stream to softsqueeze at work but of course need flac->mp3 enabled to get a nice low bandwidth; however I still want to stream flac->wav my wireless squeezebox which works fine now. This is rather a pain with the hardcoded default for wireless. The user should decide what bit rate is suitable for what player as it is already implemented. If they select 0 they should get wav from flac with a squeezebox; regardless of if it is wired or not. I believe this feature is ill advised and should be turned off or at least have the option to turn it off. Users should just use the bitrate throttling setting if their wireless cannot handle the bandwidth. It is simple enough: if you get dropouts either fool with your antennas and device placement or dial back the bitrate or both.
since I HAVE been working on a solution, I'll take this on. Since it is also bound with bug 33, I'll mark 33 as a dupe of this one.
*** Bug 33 has been marked as a duplicate of this bug. ***
Just something I though of. This issue seems to revolve around having good out of the box performance while making adjustments in the bit rate easy enough to do for "power users". Perhaps it might bw as simple as maintaining the maxmimum bitrate setting that worked great IMHO and having it default to a modest 128 kbps rather than an unthrottled 0. I assume convert.conf would stay largely the same to defined dirences between slimp3's, squeezeboxes, software players, etc. As I said I would personally note differentiate between wired and wireless in a hardcoded manner however having them a different device type/subtype in convert.conf might be useful; ie. squeezebox/squeezeboxwired/squeezeboxwireless matching all squeezeboxes, wired ones, and wireless ones respectively.
That could be a good short term solution, which I have used before. I dont think squeezebox needs to be slit in convert.conf, but it certainly could benefit from having slimp3 entries instead of relying on *. However, max bitrate would take care of the whole thing if proper defaults are set. If Dean has no objections, I can do that right away, then add the new UI for this when its ready.
I'd prefer to wait until the comprehensive solution. That said, softsqueeze FLAC playback should not be transcoded, softsqueeze should indicate that it's connected via a wired connection, which will cause the server to try to transcode first.
Just out of curiosity what is the "comprehensive solution"; or more accuratly what does the comprehensive solution give us beyond this slight, quick change. I ask this out of curiosity as to what other features one needs (or would get) beyond the already implemented bandwidth cap in the player settings and the general transcoding settings in covert.conf. Now I know that the implementation right now could be rather kludgy but it seems to work pretty well. In terms of priorities I, personally, would place native flac a lot higher than making this exquisitly elegant ;-D but that's just my POV. Of course since AFAIK only Sean does firmware it's probably moot.
Kevin is working on a new user interface for configuring the transcoding settings. This, along with sensible default values should make life a lot better for a lot of users. Maybe Kevin can send you a screen shot for what he's working on and you can give us some feedback.
Created attachment 25 [details] sample player setting UI there is only a UI for it right now, that Dean and I worked out. I don't yet know how to implement it with the current functions in Setup.pm. I've attached the UI sample here. It will be a player setting that will be made up of globally enabled server options taken from convert.conf. All I have so far, is a close approximation implemented. Given time, I can commit this solution, but there are other thigns first.
Created attachment 26 [details] current UI based on what setup.pm can do This is what I've managed so far based on what the setup module seems capable of. I can commit this UI now if that's desired, but I plan to try to create a new input template to at least have a pulldown for input formats with more than one option. The setup module needs to be reworkd in order to handle the separate pulldowns in the other attachment.
OK so I looked at the two UIs and I really can't help but coming back to what we are trying to acheive here and that I think we may be overcomplicating a simple situation: Axioms: 1. For the forseeable future there will only be one lossy way to stream; to wit MP3. 2. For the forseeable future there will only be one or perhaps two lossless ways to stream; to wit WAV/AIFF and perhaps FLAC. From the users perspective all they really need is a selection, on a per device basis, as to whether to stream lossless or with some compression (and perhaps later an option to transcode through FLAC if that becomes native). The finer points of coversion should only be tweaked from their defaults by experts and as such the convert.conf text file is probably sufficient. Trying to put all the permutations in a web view in a comprehensible manner would be quite difficult. Thus based on the player limitations all the file conversions are defined by the defaults in convert.conf and then the 0-320 setting takes care of the specific transcoding if required (having a dropdown here for the values and starting with a lower default, say 128 or 192, as I suggested might be desireable). I guess I am hard pressed to think of a scenario where the per player bandwidth setting does not give you everything you want. It is so simple, clear, and elegant that I really can't see the desire to replace it with the more complicate scheme. Here I must emphasize that I am not trying to be dense but I really cannot think or a reasonable scenario which is not better dealt with in the current system. Please describe it to me if I am just missing it.
done and dusted. committed to cvs May 6, 2004. Should make nightly for May 6. review it, post a new bug if you have specific issues. Bitrate setting will now control output format. Default rate will be 320, for now, so that all players work. Setting can easily be change to no limit for any player that you want to have full PCM uncompressed playback. As soon as there is a nice, solution, we'll default so that wired squeezebox will be no limit, and the rest can be 320kbps.
Great! One last comment. You may want to leave the wired squeezebox as 320 in any event. The subtle reasoning for this is that AFAIK softsqueeze ids itself as a wired squeezebox. I can't speak for others but 320 or lower is a good default rate for me since my applications for softsqueeze usually involve streaming over the net so I don't want 1.4 Mbps as a default. Of course I realize it is easy to change with the web interface (that's what I do now); however if the desired result is for it play music without *any* fooling around initially then the status quo (actually a default of 128 would be even better) is a good choice. One possible future tweak is to make the default a global server setting. Actually a logical extension of this is to have all the player settings appear on a global server setting page that can be used to change all the defaults. This is obviously a little pointless in a fairly static setup but if you will have numerous, arbitary, remote softsqueezes connecting it could really make things much faster and more convenient. My ultimate remote setup is a webpage 'Daryle's Jukebox' that I can download the java applet and launch softqueeze from any brower (with java :-)) in the world! I think we are basically there but that "New Player Defaults" page in server setting would really make it sweet.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Long list of versions is confusing for new bug filers.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.