DTS file for tests ?

[vincen]

Hi,
Would it be possible to find somewhere on Internet few DTS files
encoded in WAV or something compatible with Slimboxes ? so I can test
if it works well to use digital output of slimboxes playing DTS files
to connect to a DTS decoder ?
Thanks in advance

Vincèn

[Aylwin]

I doubt you'll find any DTS encoded audio files. Also, the Squeezebox's digital output only streams PCM so no DTS support there either.

[Yorkie]

"Uncompressed formats (AIFF, WAV, PCM)
Supports raw pass-through of uncompressed PCM audio formats
Bit-perfect digital passthrough for DTS "
According to the hardware spec.
I want to know too, anyway to direct play a DVD w/ DTS o/p and via throught the SB2 to the AV receiver?

[seanadams]

Both DTS and AC3 work. You need to rip a DTS CD to a WAV file (google for "DTS WAV ripping" for tips on which tools to use).

The data in the wav file is not PCM audio - it's a compressed multichannel encoding so when you play it on the computer or through squeezebox2, you'll hear garbage out of the analog outputs.

However, if you connect the digital output to a DTS receiver, the reciver will decode it in surround sound.

Also FLAC gets about 4:1 compression on those wav files (I forget if that was for DTS or AC3 though). The ripped WAVs contain bursts of data padded by zeroes since the data rate is lower overall than 44.1/16.

[seanadams]

PS If somebody has (or can create) a free DTS WAV file it would be a really nice resource to have.

[Yannzola]

PS If somebody has (or can create) a free DTS WAV file it would be a really nice resource to have.

This got me thinking... (uh oh)
Maybe you could host a collection of "diagnostic/test" audio files on the SlimNetwork? Maybe some rights-free test tones, channel ID's, phasing, pink noise, etc. Might come in handy...

y.

[radish]

I have a few live albums which came with a DVD with the "surround" version of the music. Exactly the same as the CD, just more discrete channels. Hopefully these are DTS (I can't actually remember) but if they're DD - is there any equivalent way of ripping a DD soundtrack for playback through the SB2?

[seanadams]

This got me thinking... (uh oh)
Maybe you could host a collection of "diagnostic/test" audio files on the SlimNetwork? Maybe some rights-free test tones, channel ID's, phasing, pink noise, etc. Might come in handy...

y.

OT: Actually one thing I would REALLY like to have a test tone plugin.

WAV files are useful, but having a function generator with arbitrary frequency controls would be fantastic.

[seanadams]

I have a few live albums which came with a DVD with the "surround" version of the music. Exactly the same as the CD, just more discrete channels. Hopefully these are DTS (I can't actually remember) but if they're DD - is there any equivalent way of ripping a DD soundtrack for playback through the SB2?

In theory ANY bitstream, PCM or not, that can be sent over s/pdif at standard sample rates should be pass-throughable by SB2. The only challenge is the ripping.

I suppose a sound card with s/pdif input should be able to record them too. The problem is some sound cards (including one particular USB dongle I know of) have problems with data errors.

[kevin]

http://www.kellyindustries.com/sounds.html

[m1abrams]

In theory ANY bitstream, PCM or not, that can be sent over s/pdif at standard sample rates should be pass-throughable by SB2. The only challenge is the ripping.

I suppose a sound card with s/pdif input should be able to record them too. The problem is some sound cards (including one particular USB dongle I know of) have problems with data errors.

Is this only true with SB2? Or will this work with SB1 also? I assume SB2, which gives me a very good reason to upgrade ;).

[kevin]

Is this only true with SB2? Or will this work with SB1 also? I assume SB2, which gives me a very good reason to upgrade ;).

DTS-WAV will not work with SB1, only SB2.

[smst]

In theory ANY bitstream, PCM or not, that can be sent over s/pdif at standard sample rates should be pass-throughable by SB2. The only challenge is the ripping.
I'm looking for ideas about sending DTS (from a DVD) in this way. I'll explain what files I've got, and what I've tried, first. After that I'll be asking for advice/suggestions on sending digital data over the SB2 without a WAV wrapper.

I've ripped a DTS file from a DVD (an audio DVD (but DVD-Video!) with a DTS stream), by using standard DVD ripping software to grab the VOB and VOBrator to pull the DTS file out. That gives me a file with extension .DTS, which has the correct sync word (0x7ffe8001) at the start and plays in the VideoLAN Client (downmixed to stereo -- I've just used VLC to determine whether the file is parseable).

I've then converted the DTS file to a DTSWAV file, by converting each successive 14-bit value to a big-endian 16-bit value (with sign bit extended into the top two bits), and wrapping the whole thing in a WAV file with appropriate headers. (Aside: if I cheat a bit and tell the WAV file that its rate is 44100 instead of 48000, then burn it to CD, I can get my amp to recognise the DTS stream. But it sounds like, as somebody else said on these forums, a horse galloping round the room.)

But the file doesn't play through the SB2, nor does it play through VLC. I can successfully play other DTSWAV samples through the SB2 (such as those from Kelly Industries), and I believe my file conversion was successful.

(Aside: I originally did the conversion with a third-party utility, but when the file didn't play I did it myself with a quick Python script. The resultant file does contain the expected sync values at regular intervals, so it looks proper to me.)

I think the sticking point is the bitrate: the DTS specs mention three bitrates. 768 kbits/s and 1536 kbits/s (my DVD uses the latter) are used for DVD-Video, but seem to be forbidden for a DTS CD; it's a DTS CD which uses the WAV wrapper I constructed above, so my guess is that any decoder which receives a DTS signal in that format and at that bitrate will refuse to decode it (and may not even be capable of handling the bitrate). (Aside: I may try transforming a sample DTSWAV the other way, to DTS, to see if VLC will play that... I think the DTS CD bitrate is forbidden in DTS-Video, so that probably wouldn't work either.)

To summarise, I've tried wrapping a raw DTS file sourced from DVD-Video in a WAV file, the goal being to use the WAV file as a simple already-understood transport mechanism so that the underlying DTS data can be passed through the SB2 to the DTS-aware receiver. It doesn't work for my DTS file, so I'm wondering how I could pass the original bitstream straight through to the receiver. I don't know how to do this, and I have a number of questions related to it (some of which may be invalid to start with... I have an insufficient understanding of all this!):

How do I configure SlimServer to pass a DTS file straight through (no conversion)?

Is that enough to get the bitstream out of the SB2's S/PDIF? Or does the firmware need to be able to grok the stream's contents somewhat? Does it perhaps just need to know that there's another format, even more "raw" than WAV (and not to expect WAV-related transport data)?

I have too little technical knowledge here!

If it's helpful, I could provide the DTS file I've ripped (and my converted DTSWAV file, if somebody thinks I've missed something in that area -- I'd be happy with it if it could be made to work as it's not hard to do the conversion). The DTS file is about 50MB, and doesn't lose much when zipped.

BTW, IMO re-encoding is not an option. For one thing it would require a non-free (beer and speech) utility to do so; for another, it's a lossy encoding applied over an existing lossy encoding, so the quality is going to suffer. And it's not so elegant. :)

Thanks in advance for any suggestions!

Cheers,
Steve

[smst]

I wrote:

(Aside: if I cheat a bit and tell the WAV file that its rate is 44100 instead of 48000, then burn it to CD, I can get my amp to recognise the DTS stream. But it sounds like, as somebody else said on these forums, a horse galloping round the room.)
I can no longer reproduce this, so perhaps I made a mistake. I have heard that sound during my tests, but I can't remember now what I did to produce it.

[Jeff Moore]

2005-10-10-19:22:51 smst:
> smst Wrote:
> > [...] But it sounds like, as somebody else said on these forums,
> > a horse galloping round the room.)
> I can no longer reproduce this, so perhaps I made a mistake. I have
> heard that sound during my tests, but I can't remember now what I did
> to produce it.

It was the pony. You let it run loose.

[seanadams]

The DTS file is about 50MB, and doesn't lose much when zipped.

This indicates that you have the raw DTS data at its nominal bit-rate, not the CD bit rate (44.1 * 16 * 2 == 1.4112 Mbps).

Since SB2 does not know anything about DTS, what you need is a file that has been padded the same way as the data on a DTS CD. Then when it passes it though, it comes out in the correct bursts.

[smst]

This indicates that you have the raw DTS data at its nominal bit-rate, not the CD bit rate (44.1 * 16 * 2 == 1.4112 Mbps).

Since SB2 does not know anything about DTS, what you need is a file that has been padded the same way as the data on a DTS CD. Then when it passes it though, it comes out in the correct bursts.
Yes, exactly -- but when I convert it into that format, it's completely unplayable (by other apps that I know can play DTS files or DTS CD / DTS WAV files). As I mentioned above (I know, it's a long post!), I think the bitrate used in the DTS stream is incompatible with the DTS WAV format.

What would it take for a SB2 to be able to pass the raw DTS through? I'm not asking for the box to be able to parse and understand the stream, just to pass the raw data out to the receiver. How do DVD players do it? (My DVD player knows nothing about DTS, but it can pass the bitstream to the receiver okay.)

[seanadams]

What would it take for a SB2 to be able to pass the raw DTS through? I'm not asking for the box to be able to parse and understand the stream, just to pass the raw data out to the receiver. How do DVD players do it? (My DVD player knows nothing about DTS, but it can pass the bitstream to the receiver okay.)

It's an extension of the s/pdif spec. Basically it allows any kind on non-PCM data (including mp3, for example) to be sent over s/pdif by sending the compressed bitstream as bursts with some headers and zeroes in between to delimit them. In order to do this encoding, SB2 would need to do some parsing of the stream in order to determine the average bit-rate to be transmitted. I can't say this would be a high-priority project or that we'd be able to implement this in the near term. However it could be done on the server with a transcoding plugin if somebody wanted to write it.

[smst]

It's an extension of the s/pdif spec. Basically it allows any kind on non-PCM data (including mp3, for example) to be sent over s/pdif by sending the compressed bitstream as bursts with some headers and zeroes in between to delimit them. In order to do this encoding, SB2 would need to do some parsing of the stream in order to determine the average bit-rate to be transmitted. I can't say this would be a high-priority project or that we'd be able to implement this in the near term. However it could be done on the server with a transcoding plugin if somebody wanted to write it.

Thanks for your reply Sean -- I appreciate you taking the time to explain this. And I do understand that firmware changes such as this are not necessarily going to be useful to the majority of users, so other items may take priority.

I'm willing to help if I can, but before I try delving into the server code (I've not really used Perl in earnest so I'd be learning a language and a problem domain at the same time) I'd like to try some experiments. If I could transform my DTS file into a binary data file suitable for sending over an S/PDIF link, can I then configure the server (through the 'types' or 'convert' config files?) to pass that test file through? Does that also need some plugin assistance? I presume from what you've said that if this was done in a plugin, there would be no firmware changes needed.

I don't have an S/PDIF connection from my PC to a receiver, but I bet I could convince some software player to generate an S/PDIF stream and write it to a file. After that (or instead of that), I reckon I could dig around for a spec to perform the process myself.

I see that projects such as ac3iec958 (http://www.theiling.de/downloads/idx.cgi/ac3iec958*?lang=en) exist to do something similar for AC3. I would naively have thought that the process for DTS would be the same, again remembering that a DVD player doesn't need to know how to parse a DTS stream... but perhaps DTS/DD streams have a similar format (so a DTS stream's bitrate can still be parsed by AC3-aware hardware), or perhaps a DVD player can just make assumptions about the stream (this is more likely true, as a DVD-Video DTS stream can only have a particular bitrate and frequency, I think).

So my first naive converter could start with similar assumptions to a DVD player (sort of) and convert the bitstream without looking into it. A more advanced converter would pull the bitrate from the header instead (not too tricky -- it's just a few bits near the start which index into a table).

I'll look into this some more later. If you could point me in the right direction, server config-wise, to streaming the padded file, I'd appreciate it.

Thanks again,
Steve

[Peterb]

Swedish Radio (SR) have done some tests with multichannel audio and there are test files that can be download from http://www.sr.se/multikanal/index.stm
Even if you don't understand Swedish you should be able to download a couple of files for testing purposes.

[seanadams]

I'll look into this some more later. If you could point me in the right direction, server config-wise, to streaming the padded file, I'd appreciate it.


I'm not really sure of all the details beyond here. A starting point would be to get the IEC spec (sorry I forget the number) which is about 60 CHF. Then figure out the source bit-rate, see what a DVD player is transmitting (maybe record it with an s/pdif input sound card) and go from there. I expect it could be done in less that 100 lines of code (perl, C, whatever) as a standalone app taking DTS in and outputting WAV. Easy to hook in via convert.conf.

[smst]

I'm not really sure of all the details beyond here. A starting point would be to get the IEC spec (sorry I forget the number) which is about 60 CHF. Then figure out the source bit-rate, see what a DVD player is transmitting (maybe record it with an s/pdif input sound card) and go from there. I expect it could be done in less that 100 lines of code (perl, C, whatever) as a standalone app taking DTS in and outputting WAV. Easy to hook in via convert.conf.

Okay, thanks. One more thing though -- if the S/PDIF-ready data is wrapped in a WAV, won't it get formatted again for S/PDIF output when the SB2 plays it?

My understanding is that, ordinarily when playing a WAV on the SB2, the PCM data is taken from inside the WAV and then encoded into a specially formatted stream to be spat out over the S/PDIF interface. If I was to do that encoding work on the server, wouldn't I need to tell the SB2 that the data is ready for spitting out?

Anyway, I'll look into all this when I can next find a spare few hours. Thanks again.

[smst]

My understanding is that, ordinarily when playing a WAV on the SB2, the PCM data is taken from inside the WAV and then encoded into a specially formatted stream to be spat out over the S/PDIF interface. If I was to do that encoding work on the server, wouldn't I need to tell the SB2 that the data is ready for spitting out?

Ah, I think I understand this better now. There are two formats, IEC60958 and IEC61937. The latter could be considered to be at the same level as PCM data (the sort of thing embedded in a WAV file), I think; either IEC61937 or "normal audio" (according to what I've been reading) can be sent over IEC60958.

So when I asked about the SB2 encoding data for S/PDIF transmission, I think I was talking about encapsulation in an IEC60958 stream, which is a valid thing to do for WAV audio data or IEC61937 data. I was worried that encapsulation would occur twice, but now I think that's not the case.

Does that sound right?

[cptkcmuscl]

Is there anything inherently wrong with putting the EAC ripped resultant wav file in a flac wrapper then having the SB2 decode that? It SOUNDS like a perfect duplicate of the original DTS audio file. Am I just more willing to put up with a kludgy approach to playing my DTS discs than others are? I plan on grabbing some AC3 snippets from movies I like and perhaps from some DVD audio discs as well and see if I can do the same thing.

Larry

[smst]

Is there anything inherently wrong with putting the EAC ripped resultant wav file in a flac wrapper then having the SB2 decode that? It SOUNDS like a perfect duplicate of the original DTS audio file. Am I just more willing to put up with a kludgy approach to playing my DTS discs than others are? I plan on grabbing some AC3 snippets from movies I like and perhaps from some DVD audio discs as well and see if I can do the same thing.

For a DTS CD, that's exactly the right approach. The DTS bitstream is already in the right format, so EAC (or whatever) plus FLAC (or any other lossless codec) is the best solution. That IS a perfect duplicate of the DTS file on the disc, and I don't think it's hacky at all.

But for a DVD, the approach must be different. For a start, EAC won't rip the audio data; it's stored in a different way to CDs. You need to use DVD-ripping software to extract the audio streams from a given chapter (say), and then you end up with a "raw" AC3 (Dolby Digital) or DTS file.

Those files won't play as-is in your SqueezeBox, and simply wrapping them in a WAV won't work either. (My earlier attempt to convert to the DTS CD format also failed, due to differences in bitrates.)

This week I've successfully played AC3 files on my SB2, by pre-processing them as follows:

1. Extract the AC3 file from a chapter on an audio DVD (or a film, or whatever).

2. Use a utility called 'ac3spdif' (I'm not sure this is still being developed, but I found a Windows binary after some Googling) to produce an AU file from the AC3 file. (There are probably other utilities to do similar transformations; we're trying to encapsulate the AC3 data in an IEC61937 stream.)

3. Use 'sox' to transform into a WAV file (I've used double extensions to remind myself not to play the files on my PC!):
sox -t au myfile.ac3.au -t wav myfile.ac3.wav

4. Use 'flac' to reclaim some space and allow tagging.

I've tried adding this process to the custom 'convert.conf', but there's a snag: 'sox' in the pipeline doesn't have access to the full AU file, so it can't calculate the length of the WAV file and therefore can't write the header. I plan to write my own encapsulation utility when I get the chance, writing a WAV file directly, and I think it should be possible to make a decent guess at the padded file size and write an estimate into the WAV file header.

Now, DTS DVDs: this is essentially the same process as with AC3 files, but the encapsulation is slightly different. Instead of using 'ac3spdif' we must use something which I haven't found yet, but which I'll have a crack at writing myself in a few days. We can do essentially what 'ac3spdif' does, I think, but we just need to read the framing data differently. (That's not too hard, so it shouldn't be much of a change.)

So, Larry: your DTS CDs can be ripped to FLAC and you'll get (through the SB2, but not the SB1 as I understand it) the DTS stream played perfectly. Dolby Digital DVDs can be ripped and added to the library with pre-processing (and in future without, although you'll lose the ability to tag them). DTS DVDs can be ripped in the future, both pre-processed and with on-the-fly conversion, assuming I can find the few hours I need to get some Python code written. :-)

Cheers,
Steve

[smst]

Update on my conversion utility:

I've written a Python script which can convert an AC3 file to a WAV file suitable for streaming to an SB2. My recommendation is still that an AC3 file is pre-converted to WAV, and then to FLAC so that metadata can be set. However, my utility does estimate the output WAV file length (correctly, in my tests so far) so it should be easy enough to use at run-time (haven't tried this yet... I don't know if the Python script will just work if it's in the right binary directory).

I do need to implement some sort of burst/padding special case that I don't quite understand from the specs yet. :)

Next to do is DTS conversion. I believe I just need to (1) parse enough DTS to get the frame size (and then read the frame), and (2) write out the correct preamble (it's different from AC3). There are software DVD players out there which already play DTS streams, so I should be able to take some cues from that.

The problem with pre-converted files is that they're just WAV/FLAC. Although they play just fine on the SB2, they won't work in, say, foobar2000, or (probably) WinAmp.

I'd like to make a recommendation about how to alleviate confusion with such files, but I'd like other people's views too. I see two choices:

1. Leave the file names as "whatever.ac3.flac" (or "whatever.dts.flac"). Humans can see the embedded file type, but WinAmp/fb2k/etc will have problems playing them. SB2 will just work with a digital output, but won't work with analogue outputs (and it can't tell the difference between normal FLACs/WAVs and these special FLACs/WAVs for the analogue output).

2. Use a custom extension for converted files, say "whatever.ac3.spdif-wav" and "whatever.ac3.spdif-flac". (And "whatever.dts.spdif-wav", etc.) No danger of other software thinking, because of the file name, that the file is understandable audio. The 'spdif' and 'spdif-flac' extensions are of course open for debate.

Question for those in the know: can 'convert.conf' be configured to do something different depending on whether the player is using digital outputs? In particular, we'd probably want to convert the audio to silence for players that can't take it (or possibly get more complex and find some utility to decode the file and downmix it!).

Question about SB1: what's the situation with digital pass-through? I believe there's a firmware bug which causes the data to be corrupted in some way (bit inversion? Byte swapping?). That would affect these converted files; I guess it would also affect a standard WAV. Is that right? A utility to convert the digital files to an SB1-compensating format would be useful (and not too tricky, I think), but does it need to be applied to all WAV files or just those with the proposed special extension?

I welcome any ideas or answers.

[sbjaerum]

Update on my conversion utility:

I've written a Python script which can convert an AC3 file to a WAV file suitable for streaming to an SB2. My recommendation is still that an AC3 file is pre-converted to WAV, and then to FLAC so that metadata can be set. However, my utility does estimate the output WAV file length (correctly, in my tests so far) so it should be easy enough to use at run-time (haven't tried this yet... I don't know if the Python script will just work if it's in the right binary directory).

I do need to implement some sort of burst/padding special case that I don't quite understand from the specs yet. :)

Next to do is DTS conversion. I believe I just need to (1) parse enough DTS to get the frame size (and then read the frame), and (2) write out the correct preamble (it's different from AC3). There are software DVD players out there which already play DTS streams, so I should be able to take some cues from that.

The problem with pre-converted files is that they're just WAV/FLAC. Although they play just fine on the SB2, they won't work in, say, foobar2000, or (probably) WinAmp.

I'd like to make a recommendation about how to alleviate confusion with such files, but I'd like other people's views too. I see two choices:

1. Leave the file names as "whatever.ac3.flac" (or "whatever.dts.flac"). Humans can see the embedded file type, but WinAmp/fb2k/etc will have problems playing them. SB2 will just work with a digital output, but won't work with analogue outputs (and it can't tell the difference between normal FLACs/WAVs and these special FLACs/WAVs for the analogue output).

2. Use a custom extension for converted files, say "whatever.ac3.spdif-wav" and "whatever.ac3.spdif-flac". (And "whatever.dts.spdif-wav", etc.) No danger of other software thinking, because of the file name, that the file is understandable audio. The 'spdif' and 'spdif-flac' extensions are of course open for debate.

Question for those in the know: can 'convert.conf' be configured to do something different depending on whether the player is using digital outputs? In particular, we'd probably want to convert the audio to silence for players that can't take it (or possibly get more complex and find some utility to decode the file and downmix it!).

Question about SB1: what's the situation with digital pass-through? I believe there's a firmware bug which causes the data to be corrupted in some way (bit inversion? Byte swapping?). That would affect these converted files; I guess it would also affect a standard WAV. Is that right? A utility to convert the digital files to an SB1-compensating format would be useful (and not too tricky, I think), but does it need to be applied to all WAV files or just those with the proposed special extension?

I welcome any ideas or answers.


SB1 has bit-correct output at S/PDIF output except for a sign reversal of the samples. I get correct passthrough of DTS wav file if the sign of the samples is inverted.

Steinar

[smst]

SB1 has bit-correct output at S/PDIF output except for a sign reversal of the samples. I get correct passthrough of DTS wav file if the sign of the samples is inverted.

Steinar
Do you mean that, for each 16-bit sample, the top bit needs to be flipped?

[sbjaerum]

Do you mean that, for each 16-bit sample, the top bit needs to be flipped?

No, change 10 to -10 etc. I guess the wav samples are stored as 2-complement signed integers, so this is not equal to flipping only the MSB bit.

Steinar

[smst]

That would have been my second guess. :D Thanks.

[seanadams]

Update on my conversion utility:



Nice work!

Is there a good way of tagging the FLAC files to indicate that they contain DTS or AC3 instead of PCM? If so, then a future firmware rev could do a couple things:

- set various s/pdif control bits to reflect non-PCM data (not that any receivers care AFAIK).
- Disable the analog outputs

Also if you're willing to share your code under the BSD license we could consider porting it to the firmware so that raw DTS or AC3 can be streamed down (although this is probably not as good as FLAC since there'd be no tagging).

[smst]

Sorry for the delayed reply; I didn't see this message somehow!

Nice work!Thanks! I've run into a bit of a wall though, which I'll explain at the end (I'm not sure if I'm now trying to do something the firmware doesn't like).

Is there a good way of tagging the FLAC files to indicate that they contain DTS or AC3 instead of PCM? If so, then a future firmware rev could do a couple things:

- set various s/pdif control bits to reflect non-PCM data (not that any receivers care AFAIK).
- Disable the analog outputs
I'm not sure about a "good" way... I wonder if the FLAC format allows for any format-identifying metadata (not tags, but in the format itself). I'll look into that. For now I've just added an SPDIF_ONLY tag to my FLACs, with a value of something like "Dolby Digital". I'm sure there are better ways! I'd also like to prevent these FLACs being played in fb2k, but I think that's less likely to happen magically.

Also if you're willing to share your code under the BSD license we could consider porting it to the firmware so that raw DTS or AC3 can be streamed down (although this is probably not as good as FLAC since there'd be no tagging).I'd be happy to do so. I did look at some other utilities when I got stuck (although one, which I couldn't compile to actually test, looked like it wouldn't work so I did the opposite of what it said). When writing a utility for oneself, this is not a problem; when offering the code to the world, I guess it can be. I'll check the licences of the code I looked to for help; they're "open" or I wouldn't have been looking at them.

Conversion in the firmware might solve a problem I had with using my utility as a run-time converter (apart from the fact that I couldn't get it to easily be invoked, it being Python and not a exe file): writing an accurate WAV header was dependent on a consistent frame size throughout the source file. With a test AC3 file from a DVD, the frame size was consistent and I could write an estimate to the header which turned out to be correct. With a different test downloaded from NRK.no (http://www.nrk.no/ulyd/0.html?p_saksunivers_id=24360) I found the frame size varied over the file, so the header estimate wasn't right. When I'm relying on writing a valid WAV file so that the SB2 will play it, this can be a problem. It might be less of an issue using the firmware directly (the playing-time estimate may be wrong, but the box can play until end-of-stream).

Now, the problem I've run into: DTS files are oh-so-close to working, but not quite. I've converted one in the way I understood to be correct, and it plays back at a third of the right speed. This is probably because it's in a WAV file marked as 48000 Hz, with an average bytes per second of 192000. The real bytes per second value should be three times that, but if I set the WAV header to reflect that (increasing the bps and the block align by a factor of three) the file doesn't play at all. Is there a maximum bitrate that the SB2 can pass through to the receiver?

(The AC3 files have each frame padded to 6144 bytes, but there seem to be three times as many frames in a DTS file than in an AC3 file of similar length.)

To work around this factor of three problem, I've also tried reducing the size of the file -- by padding to 2048 bytes instead of 6144. This seems like a much better plan (although I haven't found any specs which tell me why I should be doing that!) -- but again it doesn't quite work. I get 5 seconds of working DTS audio (I get teased by the intro to the song!) before silence for the rest of the file. The DTS light on my receiver stays on, but I don't know if it's just being optimistic or if it is still receiving the data.

I'll do some more research this week (my day job is creeping into evenings a bit at the moment, so I have less time to work with), but in the mean-time I'd be interested to know of any limitations in the firmware which I might be running into.

Cheers,
Steve

[smst]

I'm going to need to capture the output from my DVD player due to a lack of progress with the DTS encapsulation (as you suggested already, Sean). I've found the Edirol UA-1D, which seems perfect for the job (I need to plug this into a laptop, so an internal soundcard won't do; the external cards I've seen don't have coaxial S/PDIF input):

http://www.edirol.com/products/info/archive/ua1d.html

Before I try to get hold of one, can anyone think of a reason why it wouldn't do what I need it to? I've been trying to educate myself on S/PDIF etc over the last few weeks, and as I understand it this device is all I need to capture the bitstream from the DVD player (or SB2). It looks right to me, but just in case anyone wiser in these ways can spot any problems...

Otherwise I'll get one (there's one on eBay right now).

[oreillymj]

Does this link from DTS give you any additional info that you don't already have?

http://www.dtsonline.com/pro-audio/products.php?ID=1002434300


BTW, it would be nice for any server-side processing of DTS-WAV's or more likely DTS-flac files to use embeddded meta data to tell the SB2 to disable the digital volume control and pass the data through unattenuated.

At the moment, for the 1 demo file I have from Kelly Industries, I have to set the volume control from the Web UI whenever I want to show off the SB2.

[smst]

Does this link from DTS give you any additional info that you don't already have?

http://www.dtsonline.com/pro-audio/products.php?ID=1002434300Thanks for the link. I think that's all covered in the specifications I have, however. (That document just doesn't cover embedding in IEC61937.)

I know roughly what needs to be done, and I can create (from the DTS data ripped from DVD) files which the receiver recognise as DTS, and which I can hear contain the right audio -- but at the wrong speed, or stuttering, or only for a few seconds. By comparing my output to that of a DVD player (which I _know_ gets it right) I should be able to work out what's going wrong.


BTW, it would be nice for any server-side processing of DTS-WAV's or more likely DTS-flac files to use embeddded meta data to tell the SB2 to disable the digital volume control and pass the data through unattenuated.

At the moment, for the 1 demo file I have from Kelly Industries, I have to set the volume control from the Web UI whenever I want to show off the SB2.
Sean mentioned some other things the firmware could do when it spots such a file, so that suggestion could go on that list. I'd not considered that myself; I've set the player's digital volume to be fixed, and use a universal remote with the volume controls punched through (so they work no matter what mode the remote is operating in). Not a solution for everyone, of course!

That's made me think... I'll try disabling ReplayGain altogether and try my files out again. I'd be very surprised if it made a difference (there's no RG values in my WAV files; I don't think the format even supports storage of same) but I'd better be sure.

That does highlight a weakness in one's overall setup with regard to DTS/DD files: we can't apply ReplayGain to them, as such an adjustment would break the data. Having said that... the AC-3 format (used for Dolby Digital) does carry an indicator of loudness, which should be respected by the sound reproduction equipment... I wonder if that could be tweaked to normalise it somewhat? That's pie-in-the-sky at the moment, but I may look into that once I've got the basics sorted. :)

[oreillymj]

Well anything which alters the bitstream from the PC until it gets to the digital output will result in white noise from the receiver, so that's why the digital volume control needs to be disabled.

I'd be surprised if Replaygain was altering the bitstream as I don't think that WAv files can be "tagged" with the gain meta data and it's unlikely the DTS-flac files you have could have been processed by any of the replaygain type utilities.

But I suppose it's another varialbe to remove from the equation.

[oreillymj]

BTW - just for the hell of it last night, I thought I'd stream the Kelly's Industry http://www.kellyindustries.com/downloads/dts-44k_diatonis_soal.zip DTS file to my SB2 as a flac file.

There were a few surprising results.

1) The WAV only compressed from 59mb to 56mb when converted to flac. I was expecting a much better compression ratio, based on a post by Sean earlier saying that DTS files were padded with 0's. I was expected to shrink the file by maybe 40-50%. BTW- the flac compression was set to -8 (highest compression)

2) The flac file would not stream to the SB2 without breakup. I'm not sure what the problem is, but even though the reception of my 802.11g network is 80-90% (and the SB2 was the only Wireless device on it), the SB2 did not seem to be able to fill it's buffer quickly enough to keep the music from breaking up. When I looked at the buffer fullness indicator, it seemed that when the SB2 was paused , the buffer would fill to 94%, then when I unpaused, the indicator dropped in steps of 10% until the audio started to break up.

Someone mentioned in another thread that the SB2 had 64mb RAM on board, with 32mb used for buffering. If that's correct,I would have expected to get at least 1/2 way into the file before breakup. The reality was that I only managed 10-15 seconds at a time.

[sbjaerum]

BTW - just for the hell of it last night, I thought I'd stream the Kelly's Industry http://www.kellyindustries.com/downloads/dts-44k_diatonis_soal.zip DTS file to my SB2 as a flac file.

There were a few surprising results.

1) The WAV only compressed from 59mb to 56mb when converted to flac. I was expecting a much better compression ratio, based on a post by Sean earlier saying that DTS files were padded with 0's. I was expected to shrink the file by maybe 40-50%. BTW- the flac compression was set to -8 (highest compression)

2) The flac file would not stream to the SB2 without breakup. I'm not sure what the problem is, but even though the reception of my 802.11g network is 80-90% (and the SB2 was the only Wireless device on it), the SB2 did not seem to be able to fill it's buffer quickly enough to keep the music from breaking up. When I looked at the buffer fullness indicator, it seemed that when the SB2 was paused , the buffer would fill to 94%, then when I unpaused, the indicator dropped in steps of 10% until the audio started to break up.

Someone mentioned in another thread that the SB2 had 64mb RAM on board, with 32mb used for buffering. If that's correct,I would have expected to get at least 1/2 way into the file before breakup. The reality was that I only managed 10-15 seconds at a time.

Did you compress to flac on the fly?
If so, could the high compression level (-8) cause your CPU to be the bottleneck?

Steinar

[smst]

1) The WAV only compressed from 59mb to 56mb when converted to flac. I was expecting a much better compression ratio, based on a post by Sean earlier saying that DTS files were padded with 0's. I was expected to shrink the file by maybe 40-50%. BTW- the flac compression was set to -8 (highest compression)
I believe the DTS format used on CDs (which is what's used for that Diatonis file) is unpadded, so the compression wouldn't necessarily be great. In fact, because it's not "real" audio, and therefore not the sort of thing FLAC is designed to compress well, you'd probably get worse results than on a normal WAV file.

With the WAV format I'm (still) trying to transform to, padding is introduced which the FLAC algorithms can compress well -- the final FLAC file ends up being a similar size to the original DTS file.

2) The flac file would not stream to the SB2 without breakup. I'm not sure what the problem is, but even though the reception of my 802.11g network is 80-90% (and the SB2 was the only Wireless device on it), the SB2 did not seem to be able to fill it's buffer quickly enough to keep the music from breaking up. When I looked at the buffer fullness indicator, it seemed that when the SB2 was paused , the buffer would fill to 94%, then when I unpaused, the indicator dropped in steps of 10% until the audio started to break up.

Someone mentioned in another thread that the SB2 had 64mb RAM on board, with 32mb used for buffering. If that's correct,I would have expected to get at least 1/2 way into the file before breakup. The reality was that I only managed 10-15 seconds at a time.
I haven't tried it as a FLAC, but as a WAV I didn't have any problems. My SB2 is wired however, so my success doesn't necessarily mean much.

I noticed something odd about the playback of one of my unsuccessful DTS WAV experiments earlier. This version is the one that produced perfect output for 5 seconds, then went quiet. I noticed that, during the silent part, if I moved up and down in the Now Playing list (just using the up/down arrows, not actually selecting anything to play) I'd hear a fraction of a second of sound. It was too brief to tell for sure, but I wonder if the sound I heard was the next piece of sound due when the silence began -- or if it was somehow unmuting the sound briefly at the position indicated by the player. (When this track goes quiet, the track progress indicator continues to increment.)

Does anyone know what could explain this phenomenon? I don't see why moving through the playlist should change the sound output... I wonder if I placed a briefly higher load on the server every time I moved up or down, which in turn changed the rate at which the data was delivered to the player... I don't know, I'm just guessing now. It's beyond my epertise to diagnose.

[smst]

I noticed something odd about the playback of one of my unsuccessful DTS WAV experiments earlier. This version is the one that produced perfect output for 5 seconds, then went quiet. I noticed that, during the silent part, if I moved up and down in the Now Playing list (just using the up/down arrows, not actually selecting anything to play) I'd hear a fraction of a second of sound. It was too brief to tell for sure, but I wonder if the sound I heard was the next piece of sound due when the silence began -- or if it was somehow unmuting the sound briefly at the position indicated by the player. (When this track goes quiet, the track progress indicator continues to increment.)

Does anyone know what could explain this phenomenon? I don't see why moving through the playlist should change the sound output... I wonder if I placed a briefly higher load on the server every time I moved up or down, which in turn changed the rate at which the data was delivered to the player... I don't know, I'm just guessing now. It's beyond my epertise to diagnose.
Replying to myself...

I've just tried disabling the WAV->FLAC conversion (streaming my DTS-WAV file directly to the player without using FLAC) and this problem has gone away. I guess that either the encoder or decoder couldn't keep up -- I was using a low frame size which left the file essentially unpadded, so the FLAC was the same size as the WAV.

So now I have a different problem... the song sounds marginally too slow. The difference is slight enough that I wonder if it's being played back at 44100 Hz instead of 48000 Hz (the file is marked as being the latter).

[smst]

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

[oreillymj]

Just discovered the source of my dropouts.

My new neighour is running a WLAN. Even though he's setup on a different channel, there must still be some sort of interference.

I just found this post http://forums.slimdevices.com/showpost.php?p=52193&postcount=13 and since I have the exact same router mentioned, I thought I'd give some of the settings a try.

I only had to enable "protected mode" on the router to fix my dropouts. I left the 802.11 mode to auto as my PSP only has 11b and I use the handheld skin on it.

So I can now get a flac compressed DTS wav file to stream to the SB2 for native decoding and playback without break up.

I also discovered that I don't need to set the Player->Digital Volume Control to fixed. All I need to do is put the volume to max and the data is effectively passed through untouched.

DTS aside, I think this proves that flac files sent to the SB2 are passed through untouched. Some of the audiophiles on the list seem to notice a difference between wav & flac. If the SB2 was changing the bitstream of flacs, I would have got white noise from my amp.

I'm not sure exactly what you ultimately want to achieve. i.e how you are going to create your own 5.1 channel sound to stream. What I want to do is rip AC3 from concert DVD's.

But I think you should repeat your tests with flac compressed WAV s from Kelly Industries or the Swedish radio web-site and I think you'll find that the SB2 can cope fine with the de-compression

[smst]

It's cool that you got your playback issues sorted.


I'm not sure exactly what you ultimately want to achieve. i.e how you are going to create your own 5.1 channel sound to stream. What I want to do is rip AC3 from concert DVD's.
That's exactly what I want to be able to play: AC3 and DTS from DVDs. Concerts, yes, although I may be content with conversion to a lossy stereo format in those cases (depends if the surround aspect is really utilised). Mainly I want access to specially-created 5.1 mixes, such as The Flaming Lips "Yoshimi Battles The Pink Robots", or Porcupine Tree's "In Absentia" (Dolby Digital and DTS respectively).

If you rip such a stream from a DVD you won't get a WAV file, but an AC3 or DTS file. The SB2 can't play those formats natively, but with a little help at the outset from something which understands just enough of those formats, playable WAVs can be created. That's what I'm trying to achieve.

But I think you should repeat your tests with flac compressed WAV s from Kelly Industries or the Swedish radio web-site and I think you'll find that the SB2 can cope fine with the de-compression
I have tried them before, and they seem to work okay (but I will try them again having fiddled with my settings). The SB2 can decode FLAC in general, but I think that the files I'm producing are somehow harder to decode. I opine that this is either down to the DTS format being different between a DVD-sourced DTS file and the type of file on those websites, or perhaps a difference in bitrate.

Hopefully I'm wrong and there's something up with my configuration which is affecting all FLAC files (I haven't tried the downloaded files for a few days).

[smst]

A small update (but not a lot to add)...

I've bought an Edirol UA-1D, which basically gives me S/PDIF input/output (both co-ax and optical) on my laptop. I probably need to learn more about how to use it as some tests on my DVD player's output failed to yield a recording, but I did manage some minor verifications:

The 48KHz WAV files I've generated containing DTS data played back fine over the S/PDIF line, at the correct speed. My suspicion was that Bug#128 (http://bugs.slimdevices.com/show_bug.cgi?id=128) was responsible for the slowed-down audio, but until now I've not been able to be absolutely sure that the file itself wasn't somehow causing it.

I tried to record the output of the SB2 playing back a DTS-FLAC file, but the recording didn't work. I was using Audacity, and the time indicator in the recording stream seemed to get stuck... I don't know if a better free app is available for this sort of thing, but will look into it at some point. Since DTS-FLAC playback through my receiver sounds jerky, I suspect that the recording problem was down to a bad stream (but I'm hand-waving when I write that... figuratively).

I successfully recorded the output of the SB2 playing back a DTS-WAV file, and most of the data is bit-perfect... but there's the odd anomaly which I don't understand. (A 0x01 near the start of one frame has been changed to 0x02; some 0x0Ds have been changed to 0x0D0A! Maybe the bytes involved are a coincidence, but the latter looks like a newline fixup.) But I don't know whether the changes come from the SB2, the S/PDIF->USB converter, Audacity... I just don't know enough about the pipeline at this time.

Of course, the DTS-WAV files sound fine to me through the receiver so this might point to the post-SB2 stages of the pipeline being at fault when recording to the laptop (it's quite likely given that this aspect is all new to me)... but then, maybe the differences wouldn't be audible to me.

I reckon my code (for generating these files) is as complete as it'll get, and need only to be sure about the licence before I post it here. I'm happy for it to be public-domain, but I have used a 3-value lookup table from another project -- if I can find the reference material for that table it's no problem, but otherwise I'm not sure if the use of it has an effect on the licence.

Cheers,
Steve

[mondelicious]

http://www.sr.se/multikanal/english/e_index.stm

edit: oops, only read the first page before posting this. sorry

[Cleve]

I downloaded a test file from both sites shown here. I unzipped the files and placed them in my music folder. Squeezebox 3 plays them as Pro-Logic pink noise - no DTS decoding through my home theatre amplifier - and I am using the optical TOS-Link connector, not analogue.

Any suggestions? Thanks.

[seanadams]

But I don't know whether the changes come from the SB2, the S/PDIF->USB converter, Audacity... I just don't know enough about the pipeline at this time.

It is almost certainly your USB interface. We saw the same problem (errors in the LSB) when recording s/pdif using an M-Audio toslink->USB adaptor. It is very likely that your adaptor uses the same chip.

[smst]

It is almost certainly your USB interface. We saw the same problem (errors in the LSB) when recording s/pdif using an M-Audio toslink->USB adaptor. It is very likely that your adaptor uses the same chip.
Was it something which could be corrected in any way? I was going to use the interface for grabbing audio from my satellite decoder (for concerts etc); it would be a shame if that wasn't perfect.

[smst]

In case those following this thread were interested in my AC3/DTS playback utility, you can find it (and a guide to playing those formats) here:

http://forums.slimdevices.com/showthread.php?t=19260

[orrinc]

Has anyone written or found a utility that just does all of this- so I can just put a CD/DVD in a PC drive and rip it?

Thanks!

Orrin