DTS audio drop outs

[HeartWare]

(04-18-2009 01:59 AM)razza Wrote:  What I don't understand HeartWare is why the PCH causes DTS audio dropouts and my HTPC doesn't playing back the same file going through the exact same receiver and speakers?

Because the "error"-handling in the HTPC implementation is better at handling these files, which may be not totally up-to-spec.

Like I hinted above, it may be that the interleaving of the various packets in the originally muxed files places the DTS audio packets at too great a distance for the demuxer in the PCH to be able to "keep up", and that the re-muxing places them at a closer distance so that it can keep up, even though the raw binary data that makes up the DTS track is identical in the two files. On the HTPC you have much more memory, so a greater buffer can be used to overcome these problems, but the PCH has limited memory (256 Mb IIRC) which places a limit on the amount of memory that be pre-read into buffers.

Joels blog entry Martian Headsets gives a good example on why it may not always be a good thing that some programs are better at handling out-of-specs files than others, as this leads to the perceived problem you see here, namely that the files "must be in-spec as my HTPC plays them". No, it doesn't have to. It may as well simply mean that the HTPC is better at handling files that are out-of-spec than the PCH is.

In my experience, and from my - granted - limited statistical material, that is what I think is happening here. The files are - somehow - slightly off when received from the original location, but simply by changing the packaging (re-muxing) it becomes more compliant and thus crawls in under the limits set by the demuxer in your PopCorn.

Yes - it is possible that the demuxer in PCH is "too stringent", but - again - since a simple re-mux of the file often - if not always - solves the problem, it stands to reason that the original producer of the file has done something to the file that makes it off-spec - at least according to how PCH sees it - and that the MKV Tools (which is generally the tool used for re-muxing these files, from what I have seen here) is better at muxing than whatever program the original producer used.

Also, as I have stated numerous times, I have yet to see ANY problem with ANY movie I myself have converted to .MKV files using MKV Tools as a muxer, and all other things being equal, it squarely points the finger at the producing end as to the source of the problem, when it is clearly possible to make .MKV files with DTS tracks that perform 100% well on the PCH.

It would be interesting to try to see which muxer was used on various problem files to see if we can determine a commonality, and then - using the EXACT same muxer - try to re-mux it to see if that solves the problem or simply reproduces it, then to try to use another muxer to see if THAT solves it.

[mbake5]

(04-18-2009 07:30 AM)HeartWare Wrote:  Because the "error"-handling in the HTPC implementation is better at handling these files, which may be not totally up-to-spec.

Like I hinted above, it may be that the interleaving of the various packets in the originally muxed files places the DTS audio packets at too great a distance for the demuxer in the PCH to be able to "keep up", and that the re-muxing places them at a closer distance so that it can keep up, even though the raw binary data that makes up the DTS track is identical in the two files. On the HTPC you have much more memory, so a greater buffer can be used to overcome these problems, but the PCH has limited memory (256 Mb IIRC) which places a limit on the amount of memory that be pre-read into buffers.

Joels blog entry Martian Headsets gives a good example on why it may not always be a good thing that some programs are better at handling out-of-specs files than others, as this leads to the perceived problem you see here, namely that the files "must be in-spec as my HTPC plays them". No, it doesn't have to. It may as well simply mean that the HTPC is better at handling files that are out-of-spec than the PCH is.

In my experience, and from my - granted - limited statistical material, that is what I think is happening here. The files are - somehow - slightly off when received from the original location, but simply by changing the packaging (re-muxing) it becomes more compliant and thus crawls in under the limits set by the demuxer in your PopCorn.

Yes - it is possible that the demuxer in PCH is "too stringent", but - again - since a simple re-mux of the file often - if not always - solves the problem, it stands to reason that the original producer of the file has done something to the file that makes it off-spec - at least according to how PCH sees it - and that the MKV Tools (which is generally the tool used for re-muxing these files, from what I have seen here) is better at muxing than whatever program the original producer used.

Also, as I have stated numerous times, I have yet to see ANY problem with ANY movie I myself have converted to .MKV files using MKV Tools as a muxer, and all other things being equal, it squarely points the finger at the producing end as to the source of the problem, when it is clearly possible to make .MKV files with DTS tracks that perform 100% well on the PCH.

It would be interesting to try to see which muxer was used on various problem files to see if we can determine a commonality, and then - using the EXACT same muxer - try to re-mux it to see if that solves the problem or simply reproduces it, then to try to use another muxer to see if THAT solves it.

I have a problem file that was originally written using mkvmerge 2.4.0. I re-muxed the file with the exact same muxer (mkvmerge 2.4.0) and the problem was gone. I also re-muxed the file with mkvmerge 2.7.0 and the problem was resolved. It seems that it doesn't matter what you use to re-mux. The simple act of re-muxing fixes the problem. Any new theories?

[xamphear]

(04-18-2009 09:28 PM)mbake5 Wrote:  I have a problem file that was originally written using mkvmerge 2.4.0. I re-muxed the file with the exact same muxer (mkvmerge 2.4.0) and the problem was gone. I also re-muxed the file with mkvmerge 2.7.0 and the problem was resolved. It seems that it doesn't matter what you use to re-mux. The simple act of re-muxing fixes the problem. Any new theories?

I'd be very interested to see a hex diff of the original file and the one after remuxing it with the same mkvmerge. In theory they should be identical. I bet the PCH engineers would also love to see it, provided this problem is even on their radar.

[nVladik]

HeartWare I can also confirm that movies that skip for me were converted in mkvmerge 2.4.0. I didn't do the muxing myself, and when I re-mux the issue is fixed.

[luckyy]

If anyone is running Linux and would like a perl script that will automate the remuxing of a MKV, I'd be happy to share the one I wrote. It's a quick hacked script that relies on mediainfo & mkvtools, but so far it's worked fine to remux any DTS movies of mine that have the audio skip. It will keep all video/audio/subtitle tracks intact during the remux.

[De1Phi4n]

(03-25-2009 12:45 AM)jj666 Wrote:  Using the sample from page 16 on ISTAR HD 1.3 via HDMI to SONY STR-DG820:

Sample file resulted in an audio dropout at 0.30.
Remuxed using MKVMERGE 2.60 resulted in an audio dropout at 0.30.
Remuxed using GDSMUX (Haali's muxer) resulted in no audio dropout.
Demux using EAC3TO and remux with MKVMERGE 2.60 resulted in no audio dropout.
Demux using DGAVCDECNV and remux with MKVMERGE 2.60 resulted in audio dropout.
Remuxed using TSMUXER to .TS resulted in no audio dropout.
Remuxed using TSMUXER to .M2TS resulted in no audio dropout.

EAC3TO reported:
[v01] The video bitstream is encoded in a non-standard framerate.

I've been sticking to using tsMuxeR as my solution and got in the habit of doing it to every mkv with dts. I get mostly 1080p anyway but especialy if i see it is 1920x1080p (not letter boxed 1920x1040 or what have you) I definately remux it.

I'd rather just do it to all my mkv then take the time to transfer it (even via usb slave on the pch a-110 which is fater then via network/smb share drive letter) only to find it has dts drop out. I guess i could transfer the mkv to my pch and then if it has dts drop out, just remux it right there on the pch viewed from my pc via network but there isn't time for that if i haven't tested the file on the pch which i usually dont and go to watch it with wife only to find it has dts drop out, would be annoying and having to remux it then would not work or give time to watch the movie.

so yeah for me its just best to remux it in advance and then transfer the .ts or .m2ts to the pch.

speaking of which I remember reading earlier in the thread I think someone saying that .m2ts was preferable for the pch and/or in general for whatever reasons. I really thought .m2ts was more of an avchd thing that like ps3 was better at playing and thatn .ts was more standard but again while i forget the reason someone said .m2ts will actually be better for the pch

so since my method is using tsMuxeR (now using latest version 1.9.9) which is better for pch, .ts or .m2ts? wouldn't want to do the bluray disk or avchd or demux option right?

i'm thining .ts or .m2ts is best and that .m2ts is slightly preferable over .ts for the reasons that someone stated earlier in this thread I believe. would you agree?

[jj666]

.m2ts and .ts performance should be identical. I believe there is a slightly smaller filesize overhead in the .ts container. I'm using .TS in 100% of cases anyway.

Cheers,

-jj-

[De1Phi4n]

oh hm i wonder what someone was talking about either earlier in the thread or in another thread saying that .m2ts was preferable over .ts for the pch.

---

i forgot I lose chapters with the mkv if it has it. i dont think tsMuxeR transfers the chapters to the .ts/.m2ts that or those files just aren' capable of chapters or the pch isn't with those fileltypes.

so now i kind of want to keep the mkv for the chapters. thing is i dont notice if it has them until i use mkv extract to extract the subs since it looks like embedded srt subs dont work wiht .ts/m.2ts

so now its like i have to put the mkv file in mkv extract just to see if it has chapters and then I guess transfer the mkv to my pch in addition the remuxed .ts/.m2ts and the separate .srt file for that.

then I can watch the mkv with chapters and embedded subs and if no audio drop outs I can just delete the .ts/.m2ts and standalone .srt sub file.

seems like a lot to have to do only to delete if no dts audio drop outs but its better then going to watch the mkv only to have dts audio drop outs and then its too late to have to take the time to remux to .ts/.m2ts (and possibly have to extract the subs which takes additional time) when we are sitting down to wach with limited time.

having 2 copies of the same movie with diff file extension though may confuse yamj not to mention take up more space and take more time but at least its full proof and again if the mkv doens't get audio drop outs i can delete the .ts/.m2ts if it does well then i have to delete the mkv and give up chapters.

if the dts audio drop outs really are from in proper audio encoding or something and not the pch's fault then hopefully everyonea nd groups etc can learn to do it right but considering other devices dont have the dts audio drop outs hopefully syabas can fix it or at least add embedded srt sub support to .ts/.m2ts and then we just have to give up chaptes and whatever other benefits mkv has over .ts/.m2ts

[frosti]

I have upgraded my audio reciver to a Power/Processor combo (lexicon DC-1 and 5 channel power amp)
I was very dissapointed to find out that 1500 gigabyte of DTS encoded movies has some kind of a 1 second Drop Outs in them, i've invested alot of $$ in the stereo system, Now i dont know what to do, to sell my PCH? what would i get instead?

to wait for next gen PCH? or to wait for a firmware fix?

This is very frustrating!

[tosh]

my feedback on the dropouts with the sample file
PCH110 HDMI + DENON AVR 2909 > problem occurs as expected
computer hdmi+ denon avr 2909 > no problem

the problem occurs only with downloaded files from internet (1080P mkv) not with files i created from BRdiscs. remuxing fixes the issue....

since i'm not a bing fan of remuxing files , i'm wondering if other products on the market synology/dvico have the same issue ?

[TommyG]

Hi all,

I'm new user of Popcorn 110. I'm very confused that DTS audio issue exist. I have read this thread carefully and almost believe that is bad multiplexing issue. But when I try to play the same file which have DTS problem on PH on different hardware player named Dvico 6500 I was surprised. No drop outs at all! Because Dvico have the same hardware it looks like PH firmware problem.

[wvn]

I guess a firmware bugfix will be issued

[Face]

(05-14-2009 10:51 AM)wvn Wrote:  I guess a firmware bugfix will be issued

I admire your optimism, but have a look at when this thread was started

[mar_tin]

(05-14-2009 12:19 PM)Face Wrote:  I admire your optimism, but have a look at when this thread was started

We discussed this problem in detail on the hungarian forum and our reseller finally get an answer from Syabas:

Quote:"Our QA have confirmed this problem. I'm clearing my engineer's schedule to look into this issue asap."

(Btw. on the WD TV HD this problem is fixed now. We tested it.)

[tosh]

that's great news if true (could be a PR answer)