Okay, more information:

If I stream a WAV using a WAV->FLAC conversion, I find that the audio
drops out after a few seconds -- the encoder can't seem to keep up (as
I hypothesised above).

If I pre-convert to FLAC (which is what I'd be doing in real life
anyway -- I'm only testing with WAVs as it's one less manual step for
me), the file plays all the way through but the sound is choppy.  I
presume this is due to the decoder not keeping up, again because the
file compresses horribly.  As I understand it, FLAC decoding should be
the same no matter what the compression level used during encoding, so
changing the compression factor probably won't help.

A FLAC->WAV server-side conversion sounds just like plain WAV (more
below); I guess my PC is better able to keep up with the decoding.  If
that turns out to be okay, I'd want to use it for converted DTS files;
can I tell types.conf that '.dts.flac' is distinct from '.flac'?

If I stream the WAV directly, the audio is slightly slow.  This looks
like it's down to 'Bug#128'
(http://bugs.slimdevices.com/show_bug.cgi?id=128); in 'Squeezebox.pm'
(elements of which are used by 'Squeezebox2.pm', I think; my perl
knowledge is very basic!), sub 'stream', WAV files are explicitly set
to 44100 Hz.  A WAV file stores its sample rate inside its own header,
so a potential fix would be to interrogate the file for the correct
sample rate (and then choose the closest match from among those
supported).

(BTW, to pre-empt the question: I get the same sample rate problem with
a "normal" 48000 Hz WAV.)

Here, then, is the state of DTS conversion:    
- I can convert a DTS file to WAV successfully.  (I pad the frames to
  a third of the size used for AC3 files; this is a hack at the moment
  as I don't know why it should be that way.)
  
- The resultant WAV file can be played through the SB2 if it's -not-
  encoded to FLAC for the journey to the client.  My receiver functions
  in automatic mode, and it recognises the DTS stream coming from the
  SB2. That WAV file sounds slow; it's being played at a sample rate
  that's too low.
  
- If I encode to FLAC, it sounds choppy if decoded on the player.  I
  can decode on the server and it sounds okay (I think!  I've done a
  fair few tests this afternoon, and I might be mis-remembering this
  particular outcome).  Note that the fact that compression is poor for
  these files means that decoding to WAV on the server doesn't lead to
  greater bandwidth usage.
  

The ideal solution to the WAV/FLAC problem would be, in my opinion, if
the SB2 FLAC decoding performance was better.  Whether that's through
optimisation of the code, or by somehow creating a FLAC file which can
be decoded more quickly, it would seem to be the nicest solution --
we'd like to keep DTS files as FLAC for support of metadata. 
Optimising code involves firmware changes however, and of course
there's every chance that the routines are already optimal -- I just
don't know.

Slightly more hacky, but maybe easier: use 'convert.conf' and
'types.conf' (or the customised versions thereof) to cause DTS-FLAC
files to be treated as distinct from regular FLAC files, so that they
can be decoded to WAV on the server.  However this requires that
Bug#128 is fixed, because of the slowdown problem.

I don't mind trying to fix that myself, but I'll probably less
effective than somebody more familiar with the code.  If I just change
$pcmsamplerate to '?', will the sample rate be picked up from
elsewhere?  That's how MP3/WMA/FLAC seems to be handled.

I'll be happy to post my Python script soon for anyone who wants to try
converting some of their files, but I'd like to find an explanation for
the padding trick first.  (DTS files seem to contain three times as
many frames as AC3 files of similar length... I might be able to
justify this by thinking about the bitrate in each case.)  I'll try to
get that sorted soon, but I'm very busy at work at the moment and have
less time for it than I'd like.

Sean: could you comment on the FLAC decoding issue please?  And do you
have any hints for fixing (or are you able to fix) Bug#128?

Thanks,
Steve


-- 
smst
_______________________________________________
audiophiles mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/audiophiles

Reply via email to