Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[csimon]

If I enable DD output format, it seems that all output is resampled to 48Khz and all options in the sample rate box is disabled. Is there any reason for this?

I think DD supports sample rates of "up to" 48KHz.  I have strange glitches when a track changes but this only happens when DD output format is elected, which suggests to me that there might be sample rate changes occurring on the audio device - some devices apparently do emit glitches when this happens, according to posts here.  I don't particularly want resampling anyway, I don't think it adds anything to audio quality.  Does the DD format have to output at 48KHz?

[Hendrik]

We require 48kHz for DD/AC3 encoding, since lower sample rates are very badly supported by hardware decoders (if at all). In actual consumer content, you are very unlikely to find a DD stream which is not 48kHz.

If the input sample rate changes, current MC architecture has to reset the encoder, which may cause the device to lose the input lock for a brief moment, which may be what you are hearing.
Its an unfortunate limitation, which we can hopefully overcome at some time.

[csimon]

I was wondering if there's any news on this as to whether it can/will be done?

48Khz is the max that DD can support so frequencies higher than that could be greyed out, but would still like to try my music untouched and unresampled at 44.1Khz, and also to see if it gets rid of the audio glitches, both obviously affect or might affect audio quality. I don't know if my AV amp will do it (it's an 11-yr old Denon) but please provide the option for those people who can do it and want to do it to achieve max possible quality.

[millst]

DD is compressed. If you're concerned about quality, you shouldn't be using it for music. The quality loss from the compression is probably worse than the hit from resampling.

-tm

[csimon]

Except it could also be causing the audio glitches on a track change, this doesn't happen when DD is not used so the sample rate change is an obvious candidate for the glitches. If DD doesn't have to be resampled to 48Khz then it would be nice to have the option not to resample.

[Matt]

I tried routing 44100 through the Dolby Digital encoder, and it ends up playing accelerated because it's looking for 48000 (even though we tell it the input is 44100).  So I just don't think there's any way to input data other than 48000.

[Hendrik]

Its theoretically possible to encode 44100 DD, however the encoder we use doesn't do it AFAIK, plus even if it would, 99% of all external decoders would just handle it like 48000 giving you the sped up audio again.

It already is a big pain with 44.1 DTS, and that actually exists because of DTS CDs, yet the majority of devices still plays it sped up.

[csimon]

In that case, if the decoder is faulty and you can't fix it, can you please look into why the audio glitches are occurring? It only happens when you issue a Next Track. When MC advances to the next track as a matter of course it doesn't happen. So when MC executes an explicit Next Track before the current track has finished, does it do something different that causes the output device to reset in some way? For example, is a Stop issued first?

[glynor]

You haven't explained fully under what conditions the glitches occur.  I'm confused just by reading this.

[csimon]

When a track is currently playing and you switch to another track manually.  There is a glitch whereby the audio stops but then a very small section of the track is replayed. This I believe is symptomatic of a sample rate change which the audio device handles "badly" as it's been brought up before and other people have experienced it and this is usually the answer. But this is the first time I've had a solid idea of what's happening in my case (as previously I wasn't knowingly making a sample rate change) as I happened to notice in audio output settings that it was always outputting at 48Khz for DD and I queried it in the OP of this thread.

[glynor]

Ok.  That is related to your particular audio device and its drivers.

Changing the buffering settings in the WASAPI setup can usually solve that.  Please note that more buffering isn't always better.  There's a proper balance needed, and your audio device seems (from the behavior exhibited) to be touchy about that buffering amount.

It also could be a driver problem for your hardware, and then there isn't a solution, other than begging your vendor to fix their issue.

[csimon]

Yes, I've tried all that in the past when it's been reported before. Are you saying that it's not JRiver's problem and there's nothing different about the way Next Track is processed?