Bugzilla – Bug 16094
conversion of (hi res flac and apple lossless) --> pcm
Last modified: 2010-04-21 05:14:07 UTC
This concerns conversion to pcm of higher res apple lossless and flac files. I tried disabling the default translation of ALAC to flac, and native treatment of flac on the server, with the following results. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ALAC at 24/88.2 resulted in following error message (and no playback). [10-04-19 10:41:15.6050] Slim::Player::Song::open (408) Error: Couldn't create command line for alc playback for [file:///Volumes/media2/media/Music/iTunes%20Music/Chicago%20Symphony%20Orchestra%20_%20Bernard%20Haitink,%20conductor/Mahler_%20Symphony%20No.%201%20in%20D%20Major/04%20Mahler_%20Symphony%20No.%201%20in%20D%20Major_%20Stu%CC%88rmisch%20bewegt.m4a] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ flac at 24/88.2 similarly: [10-04-19 11:07:59.1527] Slim::Player::Song::open (408) Error: Couldn't create command line for flc playback for [file:///Volumes/media2/media/Music/iTunes%20Music/Dunedin%20Consort/Messiah%20(Dublin%20Version,%201742)/01%20Sinfonia.flac] ^^^^^^^^^^^^^^^^^^^^^^^^^ I got a similar error for flac at 24/192 (which isn't supposed to be supported anyway. I don't have any files at 24/96 to try. All of these files (ALAC at 14/88.2, flac at 24/88.2 or 24/192) are handled properly with the default methods (alac --> flac or native flac) in 7.5. All this is a concern because I intend to deploy an external DAC, and would like to take advantage of passthrough of uncompressed PCM (which is claimed for transporter.) Also, in principle, it makes sense to try to let the server (which has plenty of spare CPU capacity) and the network (hardwired) handle more of the load and the music players less.
What version of Squeezebox Server are you running (the summary above says 7.5.X which is not an actual version)? Is the server connection to the network wired or wireless? What type of squeezebox is the target player in these tests? Is the connection to the player wired or wireless? I realise that a couple of those questions may not germane at this point but I'm just trying to gather all the information at one time.
(In reply to comment #1) Server version: Version: 7.5.0 - r30464 @ Thu Apr 1 05:38:26 PDT 2010 My connections are wired. What type of squeezebox is the target player in these tests? One SB3, one Transporter. Here the plot thickens. I tried removing the synchronization between the two players and got different results. With alac --> flac and native flac disabled on the server: with 24/88.2 alac, on transporter I got white noise played, and on the SB3 I got the same "can't create command line" error. with 24/88.2 flac on transporter I got music, and on SB3 I got the "can't create command line" error. with 24/192 flac both players, "can't create command line" error. The only truly objectionable result is the white noise with 24/88.2 alac. But what I really would like to be able to do, once my external 24/192 DAC arrives, is to create PCM for arbitrary resolution alac or flac, on the server; and to pipe this PCM through the transporter to DAC. (And what I would really, really like to do is exactly the same thing with a cheaper player, since I propose to bypass most of the capabilities of the transporter.) Can this be achieved (say with the transporter) with a specially written line in convert.conf ? Thanks.
(In reply to comment #2) > Can this be achieved (say with the transporter) with a specially written line > in convert.conf ? > Possibly, in some cases. But in general, the transcoding framework assumes that PCM output from a transcoder is always 2/16/44100. That is why you get the noise from ALAC. The only supported mechanism for the sort of thing you are trying to do is to stream FLAC to the player. It will still be bit perfect. Also, you will not be able to stream higher than 24/48000 through the SB3. When synced, all devices get the lowest-common-denominator capability. So, I guess the answer is, no - you cannot transcode to PCM at those sample-rates. By disabling ALAC->FLAC and FLAC->FLAC you have effectively disabled the ability to play higher-rate tracks in those formats.
(In reply to comment #3) > (In reply to comment #2) > > > Can this be achieved (say with the transporter) with a specially written line > > in convert.conf ? > > > > Possibly, in some cases. But in general, the transcoding framework assumes that > PCM output from a transcoder is always 2/16/44100. That is why you get the > noise from ALAC. > > The only supported mechanism for the sort of thing you are trying to do is to > stream FLAC to the player. It will still be bit perfect. > > Also, you will not be able to stream higher than 24/48000 through the SB3. When > synced, all devices get the lowest-common-denominator capability. > > So, I guess the answer is, no - you cannot transcode to PCM at those > sample-rates. By disabling ALAC->FLAC and FLAC->FLAC you have effectively > disabled the ability to play higher-rate tracks in those formats. OK, thanks. But flac --> pcm did work at 24/88.2, so it should also be possible to do alac --> flac --> pcm on the server, on the fly, at res up to 24/96 and send this to the transporter. I agree, there is not much point in this, since the default treatment alac --> flac works, but since you put the possibility of conversion to pcm in your menus on server, you might as well make it actually work up to 24/96 for players that handle these resolutions. Thanks. up to 24/96
Yes, I guess it could be cleverer about some of these edge cases. I do not expect anything actually to be done about this other than as a side-effect of other work.
(In reply to comment #5) > Yes, I guess it could be cleverer about some of these edge cases. I do not > expect anything actually to be done about this other than as a side-effect of > other work. I think the question should now be reframed as concerning the treatment of ALAC in general. In fact, the methods for treating ALAC changed in the last few server releases, indicating that you have not necessarily found the definitive solution. You wrote (in one of your replies above): The only supported mechanism for the sort of thing you are trying to do is to stream FLAC to the player. It will still be bit perfect. Well, actually not. The current convert.conf entry for alac --> flac is alc flc * * # FT:{START=-j %s}D:{RESAMPLE=-r %d} [faad] -q -w -f 1 $START$ $FILE$ | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ - You start by converting alac to 16 bit PCM. So if I have 24 bit alac, you begin by degrading it to 16 bit. Or is this an incorrect interpretation? Then you convert PCM to flac with sox, and the conversion involves a -r resample flag, where the rate %d is provided from somewhere else. Forgive me for being a little suspicious about this as well. So the default treatment of alac will only give bit perfect results on 16/44.1, and the PCM conversion doesn't work at all on higher res files.
The faad executable provided with SbS supports 24-bit sample-size, as well as 16-bit. So 24-bit ALAC input will not be truncated to 16-bit PCM. The resample flag is only set for sox if downsampling is required for the target player. So, for Transporter, Squeezebox Touch, and most instances of SqueezePlay Desktop, 24/88200 and 24/96000 will be played with bit-perfect output (modulo any volume level < 100% or replay-gain in effect).
Man, you are working long hours. Well, you are the squeezebox engineer, and I'm just some guy who read the faad man file. But the flag -f 1 in the faad command means output 16 bit PCM; Did you change the faad program so that this is no longer so? I don't have a way to actually find out, at the moment, whether I am streaming 16 bit or 24 bit, but I am dubious about your explanation. The alac --> pcm entry in convert.conf contains [faad] -q -w -f 2 $START$ $FILE$ instead, where according to the man page, the -f 2 flag means output 24 bit PCM. But, as I mentioned, this produced earsplitting white noise when I gave it a 24/88 alac file to work on, while it should have produced a legitimate 24/88 PCM file. I have to say, the earsplitting white noise makes me suspect that you guys do not quite have a handle on this. Was faad already broken, or did you rewrite it and break it? I would contend that nothing I can do by making legitimate menu choices in Squeezebox server and then playing a supported file type at a supported sample rate ought to produce a result potentially damaging to my stereo system. (I should know in the future to turn the volume way down when trying out a new release of Squeezebox server, or a new playback option.) I thought that you had closed and abandoned this bug report, and I'm sorry to say that subsequently I put a long message on the forum (specifically the Squeezebox server forum) about these issues. If you would like to swoop in and intercept that message (which is still waiting to pass the forum moderator) that would be ok with me, as long as you are going to reopen the bug report and actually try to solve the issues that I raised. I did learn something interesting that is worth telling people about: when players are synced, they are going to get higher res files downsampled to the rate that the least capable player can handle. This seems also to be true for flac.
I don't know what man page you are reading. "-f 1" means output WAV format, "-f 2" means output raw PCM. Neither says anything about the sample-size. The default sample-size is indeed 16-bit for AAC but for ALAC it is 16 or 24 depending on the input stream and it is not possible to change it for ALAC. All the ALAC support in faad is specific to the version supplied with SbS. As I said earlier, the transcoding framework assumes that raw PCM output will be 2/16/44100. This is what it tells the player is coming. If you then send it 2/24/88200 then noise is what I would expect. Perhaps it could try to trap this, but leaving it open gives people who want to do exotic things the possibilities they need. The default configuration only uses PCM for the (very) old SB1 players.
Yes, you are right about the -f flag. I misread the man file.