MediaPortal Audio renderer - better video playback quality (16 Viewers)

[jameson_uk]

To understand why it sounds better, consider a sine wave at 16Khz sampled at 48Khz, a single period of the sine wave consists of only 3 samples!

This is what I have never understood... in an analogue world you get a sine wave. In the digital world you get a lot of 1s and 0s representing a sine wave. So once you have gone through the analog=>digital conversion processs I don't see how oversampling benefits you as the data is simply not there
Surely with an audio renderer if you take out bitstreaming then the digital to analogue is done by the DACs on your soundcard and I am struggling to see how you can improve the digital input here ?

Confused...

 

[tourettes]

Re: AW: MediaPortal Audio renderer - better video playback quality

bitsreaming indeed would disable all the video playback related quality improvements

Really all?
What about eliminating the clock drift problem?

Yes, since every single improvement is done by resampling / time strecthing the audio stream, there is simply no other way (than drop / duplicate the video frames).

 

[tourettes]

Also the difference between bitstreamed audio and lpcm is non-existing since we are talking about lossless audio formats and decoding those will always produce the 1:1 result. So implementing the bitstreaming support has the lowest priority.

With a couple of issues
(a) there is no directshow decoder for DTS-HD so only option for that is bitstreaming or downgrading it to the core standard DTS audio
(b) some directshow decoders for TrueHD actually resample everything to 16 bit / 48Khz when converting to LPCM. I have a feeling they did sort this out in recent SVN versions of FFDShow but still the case in commercial players like TMT and PowerDVD (and therefore in Directshow if you use their filters)

Yes, I know of those current limitations. But since all the video playback quality improvements would go down the drain and that was the main reason for the whole audio renderer improvement it will push the priority of the bitstreaming on quite low level

 

[tourettes]

First of all, currently we are only time-stretching, not resampling the audio. I do not know if we will need to resample, but so far I see no need.

Imho the time-stretching is better than resampling. I prefer a pitch coherent sound even with worst quality.

Actually I wouldn't ever consider using resampling to try to change the lenght of audio stream, the results would be just horrible

Instead there are few other uses for it:

1) upsampling the source. 48 to 96Khz for example. Althou I consider it just useless creation of random "noise" on high frequencies probably just coloring the audio to sound unnaturally bright (of course there are people who thing that would sound alreays better than the original )

2) To overcome some broken HW resampling (coug... Creative... cough) Some HW has just really bad resampling and for example 44.1Khz could be resampled with the audio renderer to the 48Khz that might be only "real" unmolested frequency on some HW.

One more "use case" is the WASAPI non-exclusive mode support. It will force us to resample the audio since WASAPI doesn't offer any kind of resampling support (dunno why MS didn't implement it as optional, since it would easen the application development) and in non-exclusive mode we need to provide audio in the same format as th WASAPI's internal mixer is working on. In exclusive mode this is not required since we are telling what output format the audio card will be using (which is not the case in non-exclusive mode)-

 

[arion_p]

To understand why it sounds better, consider a sine wave at 16Khz sampled at 48Khz, a single period of the sine wave consists of only 3 samples!

This is what I have never understood... in an analogue world you get a sine wave. In the digital world you get a lot of 1s and 0s representing a sine wave. So once you have gone through the analog=>digital conversion processs I don't see how oversampling benefits you as the data is simply not there
Surely with an audio renderer if you take out bitstreaming then the digital to analogue is done by the DACs on your soundcard and I am struggling to see how you can improve the digital input here ?

Confused...

Just like Tourettes said, it is not possible to retrieve any of the information that is lost during the A to D conversion. But during the D to A conversion you can remove some "Quantization Noise" introduced by A to D. A dumb D to A will output a staircase like signal. That signal would normally be "smoothed out" by the analog electronics and of course the speakers that cannot reproduce the abrupt level changes. But this smoothing out is uncontrolled and not optimal. By oversampling you can place intermediate sample to smooth out the signal in a way that "sounds" better (but not necessarily closer to the original signal).

To picture the difference compare upscaling an image in Photoshop using "nearest neighbor" vs "bicubic". The D/A effectively upsamples the signal to infinite resolution (analog signals are equivalent to having infinitely small time steps and infinitely small level steps)

But I want to emphasize that Tourettes is right: the result is not necessarily closer to the original, it just may sound better.

 

[tourettes]

But I want to emphasize that Tourettes is right: the result is not necessarily closer to the original, it just may sound better.

Lot of people will think it would sound better since the amp would say 96Khz instead of the 44.1/48Khz

But I think we should allow users to use resampling, since it would be required in any case if we want to have the WASAPI non-exclusive mode supported (please see the earlier post that explains it). There should be some good quality resampling code available as GPL so the resampling would just require to be integrated into audio renderer, not to be implemented completely.

 

[jameson_uk]

Just tried this but got unable to play stream error (works with default direct sound device)

error.log has

2010-07-28 19:40:23.021241 [ERROR][MPMain(1)]: TSReaderPlayer: Exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
2010-07-28 19:40:23.052243 [ERROR][MPMain(1)]: TSReaderPlayer:GetInterfaces() failed

Setup on this machine is Win7 x64 using Nvidia 7600 GS GPU and onboard audio (is just called ADI® 8-channel High Definition Audio CODEC in specs)

This is standard SD channel with MPEG2 audio. I have MPC Audio codec and I am guessing this is the issue? Just wanted to confirm before I download FFDShow

did try again last night and was unable to get this working at all. Monitor on this machine only supports 60Hz refresh rate and source is 99% 50Hz PAL so quite eager to see this working

Is this codec related (presumably someone else has at least tried with MPC audio codec?), hardware related or something else?

 

[tourettes]

Just tried this but got unable to play stream error (works with default direct sound device)

error.log has

2010-07-28 19:40:23.021241 [ERROR][MPMain(1)]: TSReaderPlayer: Exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
2010-07-28 19:40:23.052243 [ERROR][MPMain(1)]: TSReaderPlayer:GetInterfaces() failed

Setup on this machine is Win7 x64 using Nvidia 7600 GS GPU and onboard audio (is just called ADI® 8-channel High Definition Audio CODEC in specs)

This is standard SD channel with MPEG2 audio. I have MPC Audio codec and I am guessing this is the issue? Just wanted to confirm before I download FFDShow

I think chemelli had similar looking log when he used "too old" ffdshow so it is quite possible that the audio decoder and renderer's arent compatible. Currently I'm focusing on ffdshow only (althou I did test that MPA was able to connect at lest on some format).

 

[tourettes]

did try again last night and was unable to get this working at all. Monitor on this machine only supports 60Hz refresh rate and source is 99% 50Hz PAL so quite eager to see this working

60Hz vs. 50Hz is approx 25% speedup and that is not currently supported (only up to 6%). I'm not sure if anyone wants to look at the movies that are having physic laws that are acting 25% speed up It might be less distrubing to watch constant stuttering.

 

[grubi]

AW: Re: AW: MediaPortal Audio renderer - better video playback quality

bitsreaming indeed would disable all the video playback related quality improvements

Really all?
What about eliminating the clock drift problem?

Yes, since every single improvement is done by resampling / time strecthing the audio stream, there is simply no other way (than drop / duplicate the video frames).

But what exactly did Reclock then (I'm talking about the original one ReClock cause I don't know the new one)?
I was using it for a long time (mabye 5 years ago) with bitstreaming and it worked great for me (no micro stuttering any longer).
From the logs it seemed that from time to time a frame was inserted into the audio stream which was not noticable.

Cheers.