I wonder if eac3to considers a PAL speedup (-speedup) for the exported subtitles.
I exported video, audio and subtitles from a M2TS stream and applied the "-speedup" option to the audio tracks (23.976Hz -> 25Hz). Then I needed to convert the exported SUPs via SupRead (export options: HDDVD, 25Hz) and SubtitleCreator to SUB/IDX.
Unfortunately, audio and subtitles are getting out of sync (subtitles after audio), the more time passes by.
So I wonder: are the SUP time stamps not fixed correctly when using the "-speedup" options or does one of the other tools introduce the problem? Would it make sense to try 23.976fps in SupRead? Does this have an influence at all if converting from SUP (BD) to SUP (HDDVD)?

I wonder if eac3to considers a PAL speedup (-speedup) for the exported subtitles.
I exported video, audio and subtitles from a M2TS stream and applied the "-speedup" option to the audio tracks (23.976Hz -> 25Hz). Then I needed to convert the exported SUPs via SupRead (export options: HDDVD, 25Hz) and SubtitleCreator to SUB/IDX.
Unfortunately, audio and subtitles are getting out of sync (subtitles after audio), the more time passes by.
So I wonder: are the SUP time stamps not fixed correctly when using the "-speedup" options or does one of the other tools introduce the problem? Would it make sense to try 23.976fps in SupRead? Does this have an influence at all if converting from SUP (BD) to SUP (HDDVD)?

I assume you are using tsMuxeR to build your streams back together ? You need to change the video frame rate to 25 and bind the subtitles to frame rate.

Here you go--I think 00216 is the mpls of interest and the clpi prolly 00011. Advise if I can provide any further info!

Thanks.

It seems that playlists 1 and 216 are identical - except that 216 has more chapters than 1. Don't know why they made the disc that way. There's a good reason, though, why eac3to chooses the playlist with more chapters. See here:

When there are two playlists with a different number of chapters, which should I use? There are good arguments either way...

Quote:

Originally Posted by magic144

are you saying that one of these 2 methods does NOT remove/compensate for gaps/overlaps - I thought eac3to would always remove gaps/overlaps when demuxing a full-disc-structure title... if this is not the case, which of these 2 methods doesn't invoke eac3to's gap removal...?

or is it simply the case that eac3to does not do ANY Video gap compensation (in any mode - i.e. it just does audio) - I guess if that was the case and that ever happened, eac3to would just flag it in an info/warning message? (never seen such a warning on any of my discs to date anyway) - is it something eac3to might handle in the future?

eac3to automatically fixes audio gaps/overlaps, but it does not automatically fix video gaps/overlaps. And the only way to fix video gaps/overlaps is to modify the timestamps of a container. So if you demux video, there's nothing eac3to can do to fix the gaps/overlaps. However, the next eac3to version will at least also complain about gaps/overlaps if you demux video (older versions didn't).

Quote:

Originally Posted by topsham

I am just starting to use eac3to and have encountered this problem. Is there a fix please?

Make sure you're using the latest eac3to version. If the problem still occurs then please post the eac3to log.

Quote:

Originally Posted by 0xdeadbeef

I wonder if eac3to considers a PAL speedup (-speedup) for the exported subtitles.

No. FPS changes for subtitles is not implemented yet. It's on my to do list, though...

MKV support for those audio and video codecs which are natively supported by eac3to should be pretty complete now. MKV tracks using other video/audio codecs may demux successfully (or not), but are not officially supported by eac3to.

If you have any MKV samples with eac3to supported audio/video codecs which are not properly handled by eac3to, please upload a small sample for me. Thanks!

MKV subtitles, chapters and attachments are still not supported at all. Maybe next week...

However, after muxing the video and audio streams with TSMuxer, the audio is about 32 seconds (!) too early - and I'm not even sure if this is consistent. As converting the EVOs to M2TS with TSMuxer alone (no audio conversion) worked perfectly, I would assume that something goes wrong here with the audio conversion. I'm not quite sure what though. Any hints?

Thanks for the hint. I'm pretty sure I read somehwere (3.06 command line help?) that the "-speedup" option was only valid for audio tracks.
But ok, obviously my fault. I must admit that I used a GUI for my M2TS conversions and used the command line the frist time for the EVOs.

It seems that playlists 1 and 216 are identical - except that 216 has more chapters than 1. Don't know why they made the disc that way. There's a good reason, though, why eac3to chooses the playlist with more chapters. See here:

Still puzzled why the older version of eac3to finds-and-picks 16 chapters correctly, but the newer doesn't expose 16 chapters anywhere? In that post you linked to, at least that movie showed the feature as being in multiple playlists; this one does not.

Well, I guess this command:

D:\>eac3to h:\bdmv\playlist\ xxxxx.mpls

is giving me the main movie playlist (& incorrect 51 chapters) every time, so apparently I've not used a proper eac3to command...

EDIT: Here are the very different results when using eac3to v2.65! Apparently 00217 is the correct mpls to choose!

eac3to automatically fixes audio gaps/overlaps, but it does not automatically fix video gaps/overlaps. And the only way to fix video gaps/overlaps is to modify the timestamps of a container. So if you demux video, there's nothing eac3to can do to fix the gaps/overlaps.

thanks again Madshi - and for the new version :-)

One more question then. Are you saying that doing something like this:-

Code:

eac3to L: 1) 2: video.mkv

rather than a blanket disc title demux would keep a VC1 stream in a container (.mkv, albeit a different one from its original .m2ts housing) and allow eac3 to fix video gaps/overlaps, and is that an existing feature or a future planned capability? If I remember rightly, you said the use of video gaps/overlaps is incredibly rare in source material - but you have seen it?

It's not. How is a sped up audio track supposed to sync with a non-sped up video track?

Well, indeed it doesn't seem to make much sense to have a seperate speedup option for each stream, either. I guess it's highly unlikely that someone wants to speed up just some streams. This also creates confusion regarding the chapter timestamps and the subtitles.
Why don't you just make it a global option?

The video was encoded using 23.976fps, just like all my encodes I have done. Should I be specifying 24000/1001 instead? Or does it not matter because its only a cosmetic issue?
And a small suggestion. It might be better to say "Demuxing these tracks may or may not produce correct results." instead of what you currently have. At least thats what I think.

Well, indeed it doesn't seem to make much sense to have a seperate speedup option for each stream, either. I guess it's highly unlikely that someone wants to speed up just some streams. This also creates confusion regarding the chapter timestamps and the subtitles.
Why don't you just make it a global option?

Applying speedup/slowdown per stream is useful when replacing audio tracks -and thus avoiding the extra processing time by applying it to the video only. Also, the original audio can be demuxed unmodified for preservation or additional manipulation.

Hi,i have previously converted dtshd and truehd tracks to lpcm for my PCH A100 but have now gotten an A110.Is it possible to convert the lpcm tracks back to dtshd or truehd without any loss in quality???Thanks.

Hi,i have previously converted dtshd and truehd tracks to lpcm for my PCH A100 but have now gotten an A110.Is it possible to convert the lpcm tracks back to dtshd or truehd without any loss in quality???Thanks.

Of course if you have the appropiate encoder (don't exist free encoders) but you don't need eac3to for this.

The most common free lossless encoder is FLAC, supported in mkv container.
You can demand multichannel FLAC support in PCH.