OK, well is there any issue processing it with eac3to?

He he, you can send him an email thru the board now (if he has it enabled). admin

eac3to says:

DTS Master Audio, 3/1 channels, 24 bits, 48kHz, dialnorm: 0dB
(core: DTS, 3/1 channels, 1509kbps, 48kHz, dialnorm: 0dB)

Is that inconsistent with MediaInfo? It's stereo with 4 tracks, right? Educate me.

MediaInfo: Audio Format : DTS XLL Format/Info : Digital Theater Systems Commercial name : DTS-HD Master Audio Bit rate mode : Variable Channel(s) : 4 channels Channel layout : C L R Cb Sampling rate : 48.0 kHz Frame rate : 93.750 FPS (512 SPF) Bit depth : 24 bits Compression mode : Lossless

thanks, bro!

EDIT: on download i have to hit request access and now i am waiting for the email
u have to approve it

EDIT2: I guess I had to be logged in to giggle
i have downloaded it now

Can you provide a sample and a link to the spec you mentioned? What is the relevant eac3to command line you are talking about?

Hopefully, Guest 3 will weigh in as my knowledge of this stuff is minimal and he has lots of experience with channel orders, etc.

Please try this and report your results:

https://rationalqm.us/misc/eac3to_3.47_test.rar

sheesh yud'a thot this wud be easy but no
10 hrs solid debugging for a 3 line fix rilly?
anyway i'll do a little regression testing and then give u a test release
i need a rest

Thank you. I will look into it.

What is your use case?
What is your command line?
Does it work with 3.36?
How do you know it doesn't apply?

Please directly answer all four of these questions. Thank you.

That is correct. It is an audio feature.

What is your use case? Adjusting subtitles without also adjusting audio and video wouldn't make much sense.

You may be able to do it with a dedicated subtitles application, such as SubtitleEdit.

I did a binary compare of the two sup files. I do see some places where the PTS values differ by 1. But that converts to an actual time difference of 22 microseconds. The resolution of the SubtitleEdit display is 1 millisecond. So that's why everything looks the same in SubtitleEdit. I guess the onl...

See below and show me the differences. Open them both in SubtitleEdit. Your OCR process is probably introducing the problem. And anyway, are we really going to obsess about a 1ms difference?

I'm not doing anything with OCR and all that.

Then which sup to look at? 6, 7, or 8? What lines? Give the start time of at least one line that is different.

I compare in SubtitleEdit for fin vs fin_NEW. It's hard to go through 700+ lines.

OK, you are overwhelming me with too much data.
Just give me the two command lines that result in the sup files that have entries differing by 0.001 when using 3.46.
I don't need all those sup files, just the two command lines.
Thank you.

eac3to 3.46 was released. Thank you all for reports and testing.

thx harry i'm on it

Great, thank you. Now looking forward to you testing the subs issue you reported.

thank you ladies yer taste is unpeckable

now go test 3.46_test or yul get a spanking

Re-download the eac3to_3.46_test version and this should be fixed.

stoopid moi
when i fixed the m2ts list mode i broke the disk mode
now both shud be woiking

HPotter, you are doing a fantastic job of testing and reporting.

https://rationalqm.us/eac3to

eac3to_3.46 test was updated: * Added marking of hidden streams. :salute: Curly * Fixed failures with some UTF8 paths. :salute: HPotter * Disabled -r8brain as it is broken. If it is specified a warning is printed and it is not enabled. :salute: jul059 * Fixed regression to subtitles demuxing from bl...

I have duplicated this. DGDemux does it correctly and because DGDemux and eac3to are using the same algorithm it should be fairly straightforward to find out why the results are different. Investigating...

https://rationalqm.us/eac3to

That's our main distribution point.

Please re-test with eac3to_3.46_test version in main binaries folder. The debug prints were removed so don't expect to see them.

Thank you for your assistance in resolving this issue.

Gonna look at yer other problem now.

Guys, here is an initial test version eac3to_3.46_test: * Added marking of hidden streams. * Fixed failures with some UTF8 paths. @ HPotter Can you please verify this with the issue we have been working on? I modified the fix slightly and need to know if it is still okie-dokie. Working on some more ...

Guess my theory was right. There are lots of those calls. Either have to go for all of them now or wait for you to hit new ones. Keep me informed if you run into new instances using your unicode strings.

Thank you!