Woo Hoo!

So I replaced the alac binary with version 2.0.0 on Mac OS X and attempted to play a 24/96 Apple Lossless file.  The file does play but at the wrong speed.  This is when transcoding to flac.  If I disable flac and let it stream as PCM I only get noise output on the player.  This was tested on both the Transporter and a Classic.  It sounds like it is playing the 24/96 as 24/44.1 when transcoding to flac.  This experience is similar to bug 15119.

Yes, PCM won't work. All PCM from transcoders is assumed to be 44.1/16/2

But FLAC should work. The binary should be outputting a WAV header (so long as the -r option is not used) and flac should use this to encode correctly. With just "alac | flac" then it will only play on a Transporter, of course. You would need a sox-based pipeline to support downsampling as well. Perhaps:

alc flc * *
	# FD:{RESAMPLE=-r %d}
	[alac] $FILE$ | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ - 

I don't know if the scanner correctly detects the samplerate of ALAC file. It would need to for downsampling to be invoked. Check what the Web-UI says about the file.

Thanks Alan.  The scanner does seem to be correctly determining the sample rate so I will give that command a try and report back.

Turns out alac has a bug that it's reading the wrong place in the file for the sample rate, and thus can't support 88.2 or 96 or anything larger than 16 bits.  Will be more work to work up a patch so it can read the correct sample rate from the file.

By "larger than 16 bits" I meant the field it's currently reading for sample rate is a 16-bit field, one of several places MPEG-4 stores sample rate.  I didn't mean it would only support 16-bit files.

Is this a P1 for 7.5.0? Sounds like a great thing, but please review given other 7.5.0 tasks. Propose moving this one back to P2.

Agreed, it was a P1 when I thought it would be a simple task of compiling a new 
build.  Now that we find it's broken and requires work on a patch, it's not 
going to happen.

(In reply to comment #6)
> By "larger than 16 bits" I meant the field it's currently reading for sample
> rate is a 16-bit field, one of several places MPEG-4 stores sample rate.  I
> didn't mean it would only support 16-bit files.

Andy, which field of which box is it (incorrectly) using and do you know which field it should be using?

The correct place to get samplerate appears to be the mdhd box in the 32-bit timescale field.  There is also a mostly undocumented samplerate index value in the per-track esds box, this value is a lookup into samplerate_table:

const uint32_t samplerate_table[16] = {
  96000, 88200, 64000, 48000, 44100, 32000, 24000,
  22050, 16000, 12000, 11025, 8000, 7350, -1, -1, 0
};

See Audio::Scan mp4.c which reads both of these.

The useless 16-bit samplerate is in the mp4a box, and that's where alac reads it from:

        /* sample rate - 32bit fixed point = 16bit?? */
        qtmovie->res->sample_rate = stream_read_uint16(qtmovie->stream);

Thanks. It would seem that alac was doing the right thing with the data but just putting the wrong sample-rate value in the WAV header.

For ALAC, it is actually an 'alac' box instead of an 'mp4a' box but the data seems to be the same.

I agree that the sample-rate from this box is often bogus.

The timescale from the 'mdhd' box is probably accurate in most cases for audio files but the true sample-rate probably comes from the CODEC configuration data: the 'esds' box for AAC (mp4a) and the nested 'alac' box for ALAC. I think that it is possible for this sample-rate to be different from the timescale, in which case the timescale would be used for seeking calculations but the CODEC sample-rate would be use for output WAV header.

Update hours

 == Auto-comment from SVN commit #30081 to the  repo by ayoung ==
 == https://svn.slimdevices.com/?view=revision&revision=30081 ==

Fixed bug 8620: Apple Lossless cannot fast forward/rewind 
Fixed bug 14700: Update to ALAC 0.2.0
Combined both capabilities into updates faad.

This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!