Should the bitrate limiting prefs include FLAC encoding rates for SB2? Do we
encode only when the bitrate limiting pref is chosen or in all transcoding
cases?  Kevin, want to take a stab at this one?  

sure, I've been pondering this for some time (granted, not much progress as I'm
running on about 4hrs sleep a night these days).

Right now, we only transcode when limiting is set.  "No Limit" will go with
whatever the player has set for its supported formats (SB has FLAC first,
right?).   The convert matches go in the order that the supportedformats appears
in the array.  

If we want to have a pref controlling this, simplest way that I see for doing
this is to change "NO Limit" to be "FLAC" and "Uncompressed" so that users can
force WAV/AIF if they have some reason to require it. We'll default all SB2's to
"FLAC".

Other than that, for a generic solution, I had an idea originally to have
convert.conf contain ALL known working command lines (including faad for linux),
that a new UI in teh web would have to be created to allow each file type to
have a pulldown for the conversion choice.  We could add output format to this
as a pulldown. I may need help if it comes to creating a whole new UI, as I'm
not familiar with the form creation parts of pages.pm/http.pm/setup.pm (wherever
it is ;)

SB2 does report FLAC before the PCM types, so just adding conversion rules from
all types to flac (they don't even have to be SB2-specific) will work. 

I like the idea of including FLAC and Uncompressed in the bitrate limiting menu.
One question is whether we want to offer different FLAC encoding rates? My
initial inclination is to say no - if people want to tweak their FLAC settings,
they can edit convert.conf.

The UI you're suggesting is probably a large enough change to push off till post
6.0.

yeah, the conf lines should take care of all we need for 6.0.  Maybe later we
can do a 'quality' pref, or simply reuse the same quality setting we have for
LAME and apply it to FLAC

So can I assign this one to you, Kevin? ;-)

The scope of this bug is:
1) Add conversion rules to convert.conf (compression level 0 seems like a good
start).
2) Change "No Limit" to "FLAC" and "Uncompressed", with the correct pref options
and defaults for different hardware.

I'll take a crack at it.

Created attachment 315 [details]
convert.conf to include flac

here is a convert.conf to test out.  i dont have any AIFF, and my server can't
decode WMA or AAC since I'm on linux and don't currently have the custom lines
around anywhere. I did test: ape, musepack, ogg, shorten, wav and mp3

due to issues with FLAC requirements on raw input, we'll have to deal with any
of the command options that might vary per OS.	Since i dont know what those
might be, I'm looking for comments.

Created attachment 320 [details]
updated and optimised

this is optimised after testing which decoders give out formatted pcm vs raw.

mov123 isnt' working for me, but I have no clue what it does since i've never
used it.  I tried to get command-line options but it just crashes or outputs an
error message.	Are there command-line options?  is the output only aiff?  If I
get this last one working, I jus need a UI (tho not critical unless a user
wants to insist on WAV output :)

Kevin:   can you go ahead and commit this.  vidur's working on mov123 issues.

mov123 will always output big-endian PCM bits and does not support other command
line options for format.

*** Bug 1097 has been marked as a duplicate of this bug. ***

KDF, we still default to MP3 transcoding if LAME is installed for a wireless
SB2. Seems like we should default to FLAC, even if LAME is installed. Do you
want to take a crack at that or should I?

KP reported this as 1097, so I bounced it to here, intending to fix.  I think
this line should do it, replacing Utils::Prefs line 522:

		$rate = ($client->isa("Slim::Player::Squeezebox2") ||
($client->isa("Slim::Player::Squeezebox") && !defined
$client->signalStrength())) ? 0 : 320;

eventually we need something more future-resistent, but it should work for 6.0.
 I just haven't tested because I'm not near any hardware. I think this should
allow Softsqueeze (as a SB2) to go unlimited, and it will get WAV output due to
its formats().

player default added to svn r2521.

I'm a little less into the 'No Limit" to "flac"/"uncompressed" options.  I think
we should be ok with what we have for 6.0.  Post 6.0 it would be a chance to
make a selection array pref that allows you to choose supported formats in
order, instead of having just the hardcoded formats()

I'll test mov123 if its be fixed and do that conversion line, then remark this
for 6.1

committed mov123 line to r2552.  remarking for post 6.0 for review of how best
to handle UI options

so this is still defeatable by unchecking the ?->flac rules in server settings
-> file types, right?

yes, if  user disables any line, then the server will not be able to use it. 
d_source will report a match, but will then report it disabled and move on

Is this bug resolved?

specific pref to take wav over flac isn't implemented.  it needs a UI and I
haven't had any ideas.  Any change would have to take into account that future
native formats will come.  Right now players take the preferred format first,
but another way to go is look for native formats in preferred order...and of
none matched, THEN transcode in preferred order.  This results in native WAV
playback by default. Bitrate limiting could then be used to block raw WAV in
favour of flac transocde on the following pass.  This would probably work nicely
for other native formats in time as well.

This will have to wait post 6.1

How much of an issues is this?

It would seem to be not terribly critical at this point.  As you can tell, there is one vote, but I've seen no 
mention of this kind of feature in the forums so far.  This might become a higher priority as new native 
formats are added.  This particular problem is really an issue of resources on low powered servers.

I'm not sure of how many overall users would actually prefer to store WAV and send WAV.

back to dean, as this is a ui design issue at this point.

Dean doesn't work here any more :)

Further complexity along the lines discussed in this bug, over and above what is present in 7.5, is highly unlikely.