PgcDemux 1.2.0.4 is out

[jsoto]

Version announcements links
PgcDemux v1.1.0.2 (http://forum.doom9.org/showthread.php?s=&postid=565301#post565301)
PgcDemux v1.1.0.3 (http://forum.doom9.org/showthread.php?s=&postid=567476#post567476)
PgcDemux v1.1.0.4 (http://forum.doom9.org/showthread.php?s=&postid=583164#post583164)
PgcDemux v1.1.0.5 (http://forum.doom9.org/showthread.php?s=&postid=583948#post583948)
PgcDemux v1.1.0.6 (http://forum.doom9.org/showthread.php?s=&postid=590762#post590762)
PgcDemux v1.1.0.7 (http://forum.doom9.org/showthread.php?s=&postid=601182#post601182)
PgcDemux v1.2.0.1 (http://forum.doom9.org/showthread.php?s=&postid=617433#post617433)
PgcDemux v1.2.0.2 (http://forum.doom9.org/showthread.php?s=&postid=621519#post621519)
PgcDemux v1.2.0.3 (http://forum.doom9.org/showthread.php?s=&postid=637337#post637337)
PgcDemux v1.2.0.4 (http://forum.doom9.org/showthread.php?s=&postid=642465#post642465)

---------Original post--------------------------
Vers 1.1.0.1 (01-11-2004)
- Added: Multiangle support
- Added: Menu support
- Added: Logfile creation (including audio/video delays)
- Added: Celltimes.txt creation
- Added: Tooltips
- BugFix: Bug in subpictures timestamp calculation (in second and
sucesive discontinuities)
- BugFix: Bug in subpictures extraction when buffer[0x16]!=0

jsoto

[htc10825]

no such download on both of your sites!

[2COOL]

I have downloaded it right now and it works. The only thing that's confusing is that if you put your cursor over PgcDemux.exe, the tag says 1.0.0.2. But it's really 1.1.0.1 because it says on it's window title.

Sometimes I have trouble on some sites when I use my multiple download tool so if you have one, try turning it off.

[jsoto]

Mmmm. I usually change at the same time the four things :
- main dialog version
- About box version
- Product version
- File version
Seems this time I forgot to save everything except the main dlg. I'm wondering if I also forgot to save something more... I'll check the last modifications I've done, to be sure, but seems they are there (the tooltips is the last thing I've added).

In any case, I'll upload a new version with a "version number" coherent this night.

jsoto

[jsoto]

Vers 1.1.0.2 (02-11-2004)
- New build with no changes but with version information OK

All the code was in 1.1.0.1. It was only a cosmetic mistake, sorry for the inconveniences

jsoto

[$$$]

jsoto,

this is a very useful little tool. I just found a small bug, when there is no menu/LU PgcDemux throws an error "Max LUs has been reached". A dummy menu created with PgcEdit helps to avoid this but it would be nice if the tool could handle non-existing menus correctly.

Unfotunately, the tool doesn't open via "Open with" context menu on IFO files in Explorer. Would that be difficult to add?

Thanks.
$

[jsoto]

I just found a small bug, when there is no menu/LU PgcDemux throws an error "Max LUs has been reached". I'll fix it. Thanks for the report.
the tool doesn't open via "Open with" context menu on IFO files in Explorer I'll try to do it.

jsoto

[CoNS]

Looks good. :)

For other users: The initial versions of the program was discussed in this thread: http://forum.doom9.org/showthread.php?s=&threadid=84422

[lordkiwi]

thanks for the great programs I have one request to make

Please add hot keys for the (b)lank, (k)eep and (r)eplace buttons. Right cliking is alright but its much easier to click on a cell or VOB and hit one key on the to blak keep or replace it. the ability to select multiple cells and blank or keep them simultaniously is also nice. but the hot key is just one quick property change. thanks

[jsoto]

Vers 1.1.0.3 (08-11-2004)
- Added: Shell integration: "Open with" and "drag & drop"
- Change: Change of file extensions to wav (pcm) and mpa (mpeg)
- BugFix: Error when loading IFOs without menus.
- BugFix: Padding packs were not processed.
- BugFix: LPCM audios extraction were not correct.
- BugFix: MPEG audios extraction were not correct.

Note: I'm still unsure on LPCM extraction, mainly because I do not own
DVDs with LPCM audios (I only was able to test a 16 bit 2 channels one). Also, I didn't find a MPEG2 audio, I only test with a mpeg1 layer 2.

jsoto

[$$$]

- Added: Shell integration: "Open with" and "drag & drop"
..
- BugFix: Error when loading IFOs without menus.
excellent! big thanks!

$

[Malcolm]

Hi jsoto,
there is a new multiplexing tool called 'muxman'. here's the link: http://forum.doom9.org/showthread.php?s=&threadid=86338&highlight=muxman
it's a bit rough at the moment, but if your material (audio + video) is dvd compliant and follows some rules, muxman seems to do a good job.
the author wants to add some features to the next version regarding the interface (better error messages) and most important: he wants to add a CLI!
This could be a big step forward to a 'one click (or a 'few' clicks) solution' for replacing audio streams in VOBs / DVDs.
Having a CLI muxer together with PGCDemux & VobBlanker could make it possible to control the whole process (as described in my guide) with a small GUI-tool or with VobBlanker directly.

i will keep an eye on this.

greetings,
Malcolm

[blc]

Hello jsoto

Is it possible to make PgcDemux understand PCGs with ILV units?

[jsoto]

AFAIK, it already does, even more multiangle. Does it not work for you?

Currently I'm working on PgcDemux (LPCM audios), so I'll take a look if it fails.

jsoto

[jsoto]

Vers 1.1.0.4 (19-12-2004)
- Added: 24 bit LPCM support (1, 2 and 4 channels tracks)
- Added: 96 kHz sampling frequency LPCM support
- Note: 20 bits is not supported

Special thanks to Tobi for the 24 bit samples and to mpucoder for his support.

jsoto

[Tobii]

Sorry, jsoto

I have an error message at PGCDemux.

ERROR: Max PGCs limit (300) has been reached.

You can increase the PGC limit ? :D

[jsoto]

Sure.
I didn't change the memory allocation method. I'll do it.

jsoto

[LigH]

Want to support 20 bit PCM? Search for "Twen" - or ask me for Delphi sources, if you like.

[jsoto]

Thanks LigH. I already have your sources (including doc) on my PC :) . I just need time...

jsoto

[jsoto]

Just a quick version to fix maximum number of PGCs..

Vers 1.1.0.5 (21-12-2004)
- Added: 24 bit LPCM full support
- Change: Unlimited PGCs

Note: 20 bits still not supported

jsoto

[Tobii]

Many, many thanks for the new version. :)


Can load 29593 PGCs of a VTS, within 4 seconds. Thanks!!!

Added: 24 bit LPCM full support

What have they changed or added?

[jsoto]

Can load 29593 PGCs of a VTS, within 4 seconds. Thanks!!! Gardfield (again). But.... not easy to select one in the middle, eh?

24 bit LPCM change:
Write the code in a more generic way, and (theoreticaly, not tested) support to any number of channels (1 and 2 tested, not tested 3 and 4, but should be supported)

jsoto

[Tobii]

Yes is Garfield.It works, with a little sensitivity. :p

I test 3 and 4 channel at 24 bits sample and I then let know.

[blc]

jsoto,

Yes, I have problems with demuxing PGCs with ILVUs. Starts all right but then about 33% or so done, it says "Unsynchronized VOBs". I've looked into the .IFO and PGC1 uses VOBIDs 1,2,3,5,6 and PGC2 1,2,4,5,6.

[jsoto]

Originally posted by blc
Yes, I have problems with demuxing PGCs with ILVUs. Starts all right but then about 33% or so done, it says "Unsynchronized VOBs". I've looked into the .IFO and PGC1 uses VOBIDs 1,2,3,5,6 and PGC2 1,2,4,5,6.
Sorry, but seems to me the problem is in your side :) . Did you experience any problem when ripping the DVD?

For your information:
- I've tested Alien 1 (which has a lot of ILV material) without any problem. Also, I've tested StarWars I (a couple of ILV + multiangle cells).
- "Unsynchronized VOB" error: PgcDemux reads pack by pack (2048 bytes) and test if the pack starts with 000001BA. If not, this error is issued. All packs must start with this value, it does not matter if they belong to a ILV cell or not, so this error only can be issued in the following situations:
- Error produced/copied during ripping process
- Trying to demux an encrypted VOB
- Obviously, if there is a PgcDemux bug, but I do not believe it.

Edit: I'd like to know if someone more has tested ILV material...

jsoto

[blc]

jsoto,

Yeah, you are right. Some sectors didn't have "Pack header" :-(

[jsoto]

Vers 1.1.0.6 (07-01-2005)
- Added: 20 bit LPCM full support
- BugFix: Wrong RIFF chunk size (8 bytes lower than the right value)

Note: Special thanks to mpucoder for his support in 20 bits LPCM

Some aditional useful info about 20 bits, if you are going to work with it:
- Scenarist and Muxman use a special compact wav format for 20 bits. PgcDemux uses the same.
- I do not know any player able to play this "compact 20 bits" format. If anyone knows one, please let us know
- I've released two new (small) audio tools in order to manage 20 bits and multichannel wave files:
wav20: converts from/to different precisions, including 20 bit compact.
multiwav: interleave/de-interleave some single signal wave files in one multisignal

Additional SW I've used/tested:
- WinDVD5: Plays OK mono and stereo
- PowerDVD6: Plays OK stereo, but noise in mono
- DVDAudioExtractor: Extracts OK stereo but noise in mono
- Twen: Extracts OK stereo but noise in mono.
- All Settop I've tested (4) play fine mono and stereo (48k and 96k)

Multichannel:
- I do not find any settop able to play more than 2 LPCM channels in a right way.
- Similar behaviour in PowerDVD/WinDVD, but please note I do not have multichannel HW in my PC..

jsoto
Note: iespana is not updated, I'm having problems uploading the files..

[LigH]

Nice to read! - Now I hope someone can proof that my "Twen" worked correctly, already...

[jsoto]

Vers 1.1.0.7 (26-01-2005)
- Added: Minimize box in title bar
- BugFix: PGC demuxing in menu domain failed if # language units > 1

jsoto

BTW, I have a new mirror provided by videohelp. Thanks Baldrick!

Err, this one should be my 1000th post :cool:. I do not know why it is the 1001st :confused:

[blutach]

@jsoto

Thanks for new version and congrats on 1,000 posts.

Silly question cos I only started playing around with this. Can PGCDeMux do a full demux on a VOB by Cell ID, or does it only demux PGCs?

If the latter, when we write a PGC VOB, woud it be possible to somehow uniquely identify that VOB - eg as VTS_01_0.003 for PGC 3 in VTSM 1?

Regards

[jsoto]

Originally posted by blutach
Can PGCDeMux do a full demux on a VOB by Cell ID, or does it only demux PGCs? Currently, it only demux PGCs.

Originally posted by blutach
If the latter, when we write a PGC VOB, woud it be possible to somehow uniquely identify that VOB - eg as VTS_01_0.003 for PGC 3 in VTSM 1? Seems a good idea. I'll do it. You are asking one file per VOBID, aren't you?

jsoto

[blutach]

One per VID would be good, yes.

Regards

[jsoto]

Ok then. I've also need to check if audio/video delay changes in the VID transition...

But, first, I'm going to concentrate in VobBlanker motion2still....

jsoto

[Rockas]

I don't know if this has been asked or if it has been corrected... sometime ago I used PGC Demux to, as obvious, demux a DVD and I selected the option to extract the chapters but is gave wrong values so I ask again... has this been corrected?

[Rockas]

OK... sorry... I just checked... it seems alright now :)

[Sir Didymus]

@Jsoto.

Very funny... I am using PgcDemux in a very systematic way, when I need to demux some titles, but I didn't remind the demux by cell id is not present in your applications...

Do you think you may consider this feature for a future release of PgcDemux ?

Well, original reason for the request, with possible links with NuMenu4U, wrongly envisaged by myself, is here:
http://forum.doom9.org/showthread.php?s=&threadid=88853&perpage=20&pagenumber=2

Cheers,
SD

[jsoto]

Noted, and added to the TODO list.
jsoto

[CoNS]

Hi jsoto,

PgcDemux really is a great tool. And fast, too. Thanks for sharing it on a freeware basis. :)

While processing, could you add the percentage of completion along with the status indicator bar? I.e. "xx %" to the right of the status bar?

Could you add a warning when there're already files with the same name present in the output folder? After having succesfully processed a PGC, I sometimes click "Ok", without thinking, where I should have clicked "Quit"...! And/or you could change the "Ok" button text to "Process"?

Also when I click "Abort" while processing and then quit the program, the disc writing process seems to continue (and thus lock the files in the output directory so I cannot delete them). I'm using Win2000. I have to restart my PC in order to be able to delete the output directory. So some processes seem to hang in this situation? When clicking "Abort", shouldn't the program delete the partly finished output files?

...And the finally the big request/suggestion, which would really make the program truly awesome and one of it's kind (!!): Could you implement .iso/.img support? Often, the disc I want to demux is wrapped in an image file (.iso or .img). I then have to extract the VIDEO_TS folder from the image using IsoBuster (or mount it with the above tools) in order to demux the PGC with PgcDemux. It would be great, if I could just open the image file directly with PgcDemux and select the PGC I want to demux.

[Zeul]

josoto
just some requests :D
pgcdemux would be the ideal candidate for numenu4u to use when wanting to demux from a folder on the HD instead of an iso (which dvddec muxt have)
The following inclusions would be really great.
vobid and cellid demuxing, outputting m2v and all audio streams. BUT retaining a vob file that contains all original NAV packs, sub packs, and a copy of every GOP header that follows a cell change. so for example on a vobid demux the output vob would have all navs, subs, and a single video pk(I frame) following every cell change. This is essential for accurate sub timing.
Also instead of just demuxing the cells from the PGC, how about a single pass of the menu vob, and then do a full demux of everything.

A lot to ask i know.

thanks
zeul

[Malcolm]

Originally posted by CoNS
Could you implement .iso/.img support?You can easily use the Daemon Tools (use Google to find them) to mount .iso and .img images to a virtual drive and access them as if they were original discs.

greetings,
Malcolm

[CoNS]

Yeah, I know about Daemon Tools. I use Nero ImageDrive myself (same same), but it would be nice to be able to access the image file directly in PgcDemux without having to mount the image first.

[r0lZ]

It's really a lot of work, while mounting the image is so easy!

[CoNS]

Hmm, yeah, that's really the thing, I'm not a programmer, so I have no clue how hard it would be to implement. But you should know, r0lZ, with your recent work with implementing the .iso creation feature in PgcEdit...

I can just see that there are quite a few programs out there that are able to read and process the content of image files. Like IsoBuster, Daemon Tools, Nero ImageDrive etc. Also WinRar can open an .iso file and access the files inside etc.

[jsoto]

Originally posted by CoNS
While processing, could you add the percentage of completion along with the status indicator bar? I.e. "xx %" to the right of the status bar?You're the second to ask this. OK. I'll do it.

Could you add a warning when there're already files with the same name present in the output folder? After having succesfully processed a PGC, I sometimes click "Ok", without thinking, where I should have clicked "Quit"...! And/or you could change the "Ok" button text to "Process"? Yes

Also when I click "Abort" while processing and then quit the program, the disc writing process seems to continue (and thus lock the files in the output directory so I cannot delete them). I'm using Win2000. I have to restart my PC in order to be able to delete the output directory. So some processes seem to hang in this situation? When clicking "Abort", shouldn't the program delete the partly finished output files? Mmmm. I'll look into it.
...And the finally the big request/suggestion, which would really make the program truly awesome and one of it's kind (!!): Could you implement .iso/.img support? Often, the disc I want to demux is wrapped in an image file (.iso or .img). I then have to extract the VIDEO_TS folder from the image using IsoBuster (or mount it with the above tools) in order to demux the PGC with PgcDemux. It would be great, if I could just open the image file directly with PgcDemux and select the PGC I want to demux. . No , too much work, and need to learn .iso/.img. The option to mount the image is easy for the users...

jsoto

[jsoto]

Originally posted by Zeul
The following inclusions would be really great.
vobid and cellid demuxing, outputting m2v and all audio streams. Already in the TODO.
BUT retaining a vob file that contains all original NAV packs, sub packs, and a copy of every GOP header that follows a cell change. so for example on a vobid demux the output vob would have all navs, subs, and a single video pk(I frame) following every cell change. This is essential for accurate sub timing.
I understand this is specific for menus... But I'd like to have a tool able to generate a VOB with the packs I want, so I'll take it into account...Do you want the IFrame every VOBU or only every Cell?
Also instead of just demuxing the cells from the PGC, how about a single pass of the menu vob, and then do a full demux of everything. In my understanding this has no sense... Two different VOBIDs (mainly if they are belonging to different PGCs) can have different delays, different number of audios, etc.

jsoto

[r0lZ]

Originally posted by CoNS
Hmm, yeah, that's really the thing, I'm not a programmer, so I have no clue how hard it would be to implement. But you should know, r0lZ, with your recent work with implementing the .iso creation feature in PgcEdit... I don't create the ISO myself! The job of creating the ISO is done by mkisofs.exe, which is not my work.

[jsoto]

@all
I'm currently working in VobBlanker, so do not expect a new version inmediatly.
But this is the next thing I'm going to do after the next release of VobBlanker.
jsoto

[Zeul]

@jsoto
I would like to have the I frame immediately following every NAV pk.
I meant by doing a full demux, pass in the vob and demux automatically all the vobids or cellids, each mpv & audio (from the vobs or cells depending on switch), and then create the necessary .vob holding subs/navs

thanks
Zeul

[jsoto]

Originally posted by Zeul
I meant by doing a full demux, pass in the vob and demux automatically all the vobids or cellids, each mpv & audio (from the vobs or cells depending on switch), and then create the necessary .vob holding subs/navs
I hope this can be done with a simple CLI.
jsoto

[jsoto]

Vers 1.2.0.1 (27-02-2005)
- Added: Demuxing by VOBid and CellId
- Added: Button to check audio/video delay
- Added: Percentaje of completion in title bar
- Added: Change VOB File name between VOBids
- Added: Customizable VOB file contents
- Added: Special VOB contents requested by Zeul
- Added: Number of VIDs in Log
- Added: Warning if files already exist
- Change: Button label OK to Process
- Change: CLI syntax has been modified to support new demux modes
- BugFix: CLI was completely broken.

EDIT:
Some comments on a/v delay:
Audio/video delay is different if you demux a single cell or a VobID. A/V delay in a PGC is the delay taken from its first cell. If all the PGC's transitions are seamless (usually are, but not always) this is the delay to be taken into account.
But, when demuxing by VobId or by single Cell, the audio delay can be different.
Let's see an example:
One PGC (main movie) composed by two VobIds (usually one per layer). First VobId has the same a/v delay than the PGC (obvious), but the second one can have a different one. In a similar way, the first cell has the same a/v delay, but not the others.

PgcDemux logs the delay of the demuxing process(by PGC/VID or CID)
PgcDemux GUI allows the user to check the delay of the selected demuxing process, before or without demuxing

EDIT2: Two minor bugs: :mad:
a) A/V delay check button does not check if the PGC is empty (with no cells). An unclear message pops up
b) Unreferenced material: duration time is not found in PGCs, so it is uninitialized. Visible (strange duration values) in Cell or VID list (obviously not in PGCs)

jsoto

[Zeul]

cool
Can't wait to test and implement :)

thanks jsoto

[vav]

one more bug?

pressing the 'about pgcdemux...' item takes the program into the great blue yonder... ;)
I can sure avoid that, now that I know :)

[jsoto]

Yes, another one. Well, nothing really interesting in About Box

Version 1.2.0.1
Copyright by jsoto

jsoto

[jsoto]

A bug fixing release:
Vers 1.2.0.2 (08-03-2005)
- BugFix: Crash opening About dialog
- BugFix: Unreferenced material. Duration of unreferenced cells was not initialized. Currently computed as zero (not true, but because VOB is not opened in this moment there is no way to get this info)
- BugFix: It was allowed to check a/v delay in PGCs without cells
- BugFix: A/V delay failed if the first encoded frame is not temporal sequence number 0, that is when vobu_s_ptm is different from first video pts value. Thanks to mpucoder for the clarification.
- BugFix: Wrong audio index in logfile if mpeg audio.

jsoto

[CoNS]

A possible bug in PgcDemux (latest version):

The status indicator usually works fine for me, both the status bar at the bottom and the percentage completed value in the title. But with one particular disc, the status goes straight to 100% after just a couple of seconds. However, the program continues working in the background doing the demuxing of streams and then returns with the "Completed succesfully" dialog window after a couple of minutes as usual.

No weird settings were made by me, I do as I always do: Start the program, load the .ifo, select the PGC, check a/v delay, enable option to demux video stream and disable option for logfile creation.

One more thing of relevance: The source is a backed up DVD, which I borrowed from a friend. I don't know how he backed up the disc, and he can't remember, but he must have butchered it somewhere in the proces.

When I initially loaded the disc in PgcEdit, it gave me a warning about some values not matching eachother and said it was a known bug from DVDShrink reauthor mode. I clicked ok to fix the bug and saved the disc.

And when I load the disc in VobBlanker, it shows a very weird (way too low) output size, even though I've marked to process and keep everything.

[r0lZ]

The warning is issued by PgcEdit when the number of VOB IDs stored in the header of the VTS_C_ADT table is 1, while there are really several VOB IDs in the table. The number of VOB IDs stored by DVDShrink is always 1, and it's obviously a little bug.

I don't think it's related to the problem you describe.

[jsoto]

I'd like to take a look to the IFOs, but I think they are wrong.

Initial size calculations are done using info stored in C_ADT tables (where one cell can be more than once) adding the number of used sectors. This size calculations are used to know the total number of sectrors to be processed in pgcdemux

But when demuxing (or keeping in VB) the used pointers are the ones stored in cell PlayBack table of the PGC

Summarizing,
- VTS_C_ADT table and PCG info are not coherent.
- An IFOEdit's mock strip probably will fix the problem

jsoto

[CoNS]

Hmm, yeah no doubt my source disc is messed up. But still I think it's a bit weird the way PgcDemux acted on it. See my description above.

A request: Could you add a button to check the info/attributes of the various streams in the selected PGC? I.e. display number of used subtitle/audio streams, the language of the streams, audio quality etc.?

I know I can get this information using other programs, like loading the disc in PgcEdit or IfoEdit, but it would be handy to be able to check it in PgcDemux. It would also make it easier to identify which PGC to demux if there are more on the source disc. And as far as I remember, you already have coded a similar check in VobBlanker in connection with the PGC strip function?

[sweetness]

i demux a menu cell with version 1.2.0.2.(just the audio and subpics)
now that i'm remuxing with muxman it rejects the audio file. i ran the audio file threw delaycut with CRC errors set to fix and muxman now accepts the audio file now.here is the log file.
[Input info]
Bitrate=192
Actual rate=192.000000
Sampling Frec=48000
TotalFrames=1099
Bytesperframe= 768.0000
Filesize=844707
FrameDuration= 32.0000
Framespersecond= 31.2500
Duration=00:00:35.196
Channels mode=2/0: L+R
LFE=LFE: Not present
[Target info]
StartFrame=0
EndFrame=1098
NotFixedDelay= 0.0000
Duration=00:00:35.168
====== PROCESSING LOG ======================
Time 00:00:00.000; Frame#= 1. Unsynchronized frame...SKIPPED 675 bytes. Found new synch word
Number of written frames = 1099
Number of Errors= 1
i guess the demux audio was unsynchronized.
don't know if this is a pgcdemux problem or a muxman one.

EDIT ADD LATER:
now that i'm thinking about it i stilled the menu and i got this warning in the log. there is no audio in the other pgc to test to see if the truncating caused the unsynchronized audio.

TS 05: Single Still with audio Menu LU 01, PGC 03
NOTE: Deeply scanning Menu Cells: Finding Largest IFrames
Done.
NOTE: Selected sector (relative to cell start) 3925 in Cell 1
WARNING: Truncating audio. Buttons start in the middle of cell: 1
NOTE: Selected sector (relative to cell start) 0 in Cell 2

[sweetness]

OK there is no problem with pgcdemux or muxman. it is when the menu is stilled with motion2still and menushrink has the same problem too.
this cell has the buttons active in the middle of the cell.
really don't know if this can cause other problems(play back)when the audio is unsynchronized.

[Zeul]

@jsoto
Think i have found or a bug or was it a misunderstanding between us :D When setting for only 'I' frames every 'I' frame is written, whereas the only 'I' frame required is directly after a cell change. ie:
vob1cell1 navpk
I frame
nav
nav
nav
...
vob1cell2 navpk
I frame
nav
nav
nav
...
vob2cell1 navpk
I frame
nav
nav
nav
...
etc etc

Also this may sound like i am a noob, but whatever combination of params i use in the c/l pgcdemux always crashes. So, it must be my useage :rolleyes: , please show an exmaple of a c/l

thanks
Zeul

[jsoto]

@Zeul
whereas the only 'I' frame required is directly after a cell change Ah! I'll change it in the next version.

About the CLI
Could you give me an example of CLI which causes pgcDemux to crash?

This is the CLI syntax

PgcDemux [option1] [option2] ... [option12] <ifo_input_file> <destination_folder>
option1: [-pgc, <pgcnumber>]. Selects the PGC number (from 1 to nPGCs). Default 1
option2: [-ang, <angnumber>]. Selects the Angle number (from 1 to n). Default 1
option3: [-vid, <vobid>]. Selects the Vob Id number (from 1 to n). Default 1
option4: [-cid, <vobid> <cellid>]. Selects a cell vobid (from 1 to n). Default 1
option5: {-m2v, -nom2v}. Extracts/No extracts video file. Default NO
option6: {-aud, -noaud}. Extracts/No extracts audio streams. Default YES
option7: {-sub, -nosub}. Extracts/No extracts subs streams. Default YES
option8: {-vob, -novob}. Generates a single PGC VOB. Default NO
option9: {-customvob <flags>}. Generates a custom VOB file. Flags:
b: split VOB: one file per vob_id
n: write nav packs
v: write video packs
a: write audio packs
s: write subs packs
i: only first Iframe
l: patch LBA number
option10:{-cellt, -nocellt}. Generates a Celltimes.txt file. Only in PGC/VID mode. Default YES
option11:{-log, -nolog}. Generates a log file. Default YES
option12:{-menu, -title}. Domain. Default Title (except if filename is VIDEO_TS.IFO)


And these are two simple examples which work to me (The folder "myfolder" exists)
In titles domain:
PgcDemux.exe -pgc 1 -customvob nisl VTS_01_0.IFO myfolder
In menus domain:
PgcDemux.exe -pgc 10 -menu -customvob nisl VTS_01_0.IFO myfolder

jsoto

[jsoto]

Originally posted by CoNS
Hmm, yeah no doubt my source disc is messed up. But still I think it's a bit weird the way PgcDemux acted on it. See my description above. Well, I could do a double check to guarantee the coherence between the IFO tables...but I think there are things to do with more priority.

A request: Could you add a button to check the info/attributes of the various streams in the selected PGC? I.e. display number of used subtitle/audio streams, the language of the streams, audio quality etc.? Seems feasible and not too difficult, but, again, it is not prioritary.

jsoto

[jsoto]

@sweetness and all
Truncating audio
This is currently an issue not managed by pgcDemux.
Truncating audio issue happens when:
- The original VOB has been truncated (sweetness case)
- demuxing by CellID
- demuxing by VOBID, in the second VID of a seamless PGC

And, as result, an uncompleted frame will be at the beginning of the extracted audio. This will not happen in LPCM, where the samples cannot be split between two packs. But it will be present in ac3, mpeg and dts.

The incomplete frame can be easily deleted with delaycut, but AFAIK the a/v delay will not be accurated, due this deletion. The delay error will be less than one audio frame (10.7 msec in dts, 24 msec in mpeg or 32 msec in ac3), but it will be there.

jsoto

[Sir Didymus]

I am noticing a minor "incompatibility" among PgcDemux and MuxMan: in the celltimes file produced by PgcDemux, the last entry of this file indicates, as a chapter mark, a position which is non existant (one frame beyond the end of last cell).

Trying to use directely this file in MuxMan (last releases) is producing an error. MuxMan is not detecting this anomalous condition (hope Mpucoder, distracted in his work on the VM assembler, is not reading this post... :p ), until the authoring stage is almost complete, but PgcDemux is the source of the problem, IMHO...

By the way, maybe a very bad situation would be also Jsoto, distracted in his excellent work on VobBlanker, is not reading... :scared:

Shortcoming is trivial (editing the file and deleting the last chapter mark)...

Just checked this behaviour is exactely the same as IfoEdit.
And anyway, it seems to me also IfoEdit is not correct.

Afraid if the issue is known...

Cheers,
SD

[CoNS]

jsoto, just to let you know in connection with Sir Didymus' post:

I've also experienced some problems with the chapters in the celltimes.txt file produced by PgcDemux, when I've later used the file muxing with MuxMan. I've described the problem here (http://forum.doom9.org/showthread.php?s=&postid=633091#post633091) + later replies.

[jsoto]

OK, I'll change it.
In fact, I've intentionally added the last line to produced the same output than IFOEdit...
originally posted by mpucoder
.... In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files. May be I can add a doublecheck in the length too.

jsoto

[jsoto]

Vers 1.2.0.3 (10-04-2005)
- BugFix: Demuxed audio now starts in a frame header (1)
- Added: Option to do not include last celltime
- Changed: Special VOB contents requested by Zeul. Only the first I frame per cell

(1) Originally posted by jsoto The incomplete frame can be easily deleted with delaycut, but AFAIK the a/v delay will not be accurated, due this deletion. The delay error will be less than one audio frame (10.7 msec in dts, 24 msec in mpeg or 32 msec in ac3), but it will be there.
Not true. The PTSs are related to the first header in the pack, so deleting the uncomplete frame is the right thing to do. Note this is mainly in ac3 and mpeg audio. DTS frames fit exactly in one 2048 bytes pack (two frames in 768k, one frame in 1536k) using a negligible (a couple of bytes) stuffing trick in PES header

jsoto

[CoNS]

Originally posted by jsoto
- Added: Option to do not include last celltimeIs this to fix the problem I described in the MuxMan thread? Mpucoder answered this:

Originally posted by mpucoder
In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files.In my specific case (and also the problem reported by Sir Didymus) it was a chapter beyond the end of the segment, which caused the problem in MuxMan. So the last cell should only be deleted in the celltimes.txt file from PgcDemux when one of the two situations described by mpucoder occurs, right?

[jsoto]

Yes.
In previous versions, the last line stored was the last frame number (IIRC, using 1 to n notation). In this version, this line can be skipped (this is the default).

Let's say, in a three cells pgc (or VID):
Cell 1 from 1 to FRAME1
Cell 2 from FRAME1+1 to FRAME2
Cell 3 from FRAME2+1 to FRAME3

Previous versions Celltimes.txt
FRAME1
FRAME2
FRAME3

This version Celltimes.txt
FRAME1
FRAME2

Note if the PGC (ot VID) is made of only one Cell, an empty file will be created
Last time (FRAME3) is not needed, because there aren't more frames after this one

jsoto

[CoNS]

Ah, ok.

What about the other issue with chapters too close to eachother?

[jsoto]

Finally I decided to do nothing. Chapters are extracted from a VOB, which should be a good authored one, so this issue will never happen.
jsoto

[scraper]

Hi Jsoto,

I just demuxed an mpeg1 layer2 audio by vobid. Trying to change it to wav, besweet hangs. If i kill the command-box i get this log:

Logging start : 04/13/05 , 22:43:26.

C:\movies\progs\audio\BeSweet\BeSweet.exe -core( -input c:\REQUIEM_FOR_A_DREAM\VTS06\AudioFile_C0.mpa -output c:\REQUIEM_FOR_A_DREAM\VTS06\AudioFile_C0.wav -2ch -logfile C:\movies\progs\audio\BeSweet\BeSweet.log ) -ssrc( --rate 48000 ) -profile( ~~~~~ Default Profile ~~~~~ )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : c:\REQUIEM_FOR_A_DREAM\VTS06\AudioFile_C0.mpa
[00:00:00:000] | Output: c:\REQUIEM_FOR_A_DREAM\VTS06\AudioFile_C0.wav
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +---------------------
[00:00:00:024] Stream error : Sync found after 352 bytes
When i load the file into delaycut this is the info:
====== INPUT FILE INFO ========================
File is mpeg 1 layer 2
Bitrate (kbit/s) 96
Act rate (kbit/s) 96.000
File size (bytes) 4984024
Channels mode Single Channel (Mono)
Sampling Frec 48000
Low Frec Effects LFE: Not present
Duration 00:06:55.335
Frame length (ms) 24.000000
Frames/second 41.666667
Num of frames 17306
Bytes per Frame 288.0000
Size % Framesize 17202
CRC present: NO
=============================================
====== TARGET FILE INFO ======================
Start Frame 0
End Frame 17305
Num of Frames 17306
Duration 00:06:55.344
NotFixedDelay 0.0000
=============================================
I then demux in dvddecrypter, splitting by vobid and delaycut gives this info:
====== INPUT FILE INFO ========================
File is mpeg 1 layer 2
Bitrate (kbit/s) 224
Act rate (kbit/s) 224.000
File size (bytes) 5039328
Channels mode Stereo
Sampling Frec 48000
Low Frec Effects LFE: Not present
Duration 00:02:59.976
Frame length (ms) 24.000000
Frames/second 41.666667
Num of frames 7499
Bytes per Frame 672.0000
Size % Framesize 0
CRC present: NO
=============================================
====== TARGET FILE INFO ======================
Start Frame 0
End Frame 7498
Num of Frames 7499
Duration 00:02:59.976
NotFixedDelay 0.0000
=============================================
Any ideas?? :confused:

Sorry for the lengthy post, btw.

Regards, JP

[jsoto]

Hi,

Seems pgcDemux is demuxing something wrong... Note that the duration is calculated by delaycut using the bitrate and the file size.

Things to check:
a) Try pgcdemux 1.2.0.2
http://jsoto.posunplugged.com/tools/PgcDemux_1202_exe.zip

b) Are your IFOs ok? Could you do an IFOEdit's mock strip and test again, please?

If nothing works, please send me your IFOs and the beginning of the first Cell (Use CutFile to cut 1 MB or less)

jsoto

[scraper]

Will do that when i get home from work tonight...

[Sir Didymus]

@Jsoto.

Hi! it seems also demuxing by PGC have some glitches in the new PgcDemux release:

Here is the log file generated with 1203:


[General]
Total Number of PGCs in Titles=1
Total Number of PGCs in Menus=5
Total Number of VobIDs in Titles=1
Total Number of VobIDs in Menus=4
Total Number of Cells in Titles=16
Total Number of Cells in Menus=4
Demuxing Mode=by PGC
Demuxing Domain=Titles
Total Number of Frames=131801
Selected PGC=1
Number of Cells in Selected PGC=16
Selected VOBID=None
Number of Cells in Selected VOB=None
[Demux]
Number of Video Packs=1741296
Number of Audio Packs=146437
Number of Subs Packs=460
Number of Nav Packs=11515
Number of Pad Packs=0
Number of Unkn Packs=0
[Audio Streams]
Audio_1=None
Audio_2=None
Audio_3=None
Audio_4=None
Audio_5=None
Audio_6=None
Audio_7=None
Audio_8=None
[Subs Streams]
Subs_01=0x20
Subs_02=None
Subs_03=None
...



And here it is the same produced with 1202:


[General]
Total Number of PGCs in Titles=1
Total Number of PGCs in Menus=5
Total Number of VobIDs in Titles=1
Total Number of VobIDs in Menus=4
Total Number of Cells in Titles=16
Total Number of Cells in Menus=4
Demuxing Mode=by PGC
Demuxing Domain=Titles
Selected PGC=1
Number of Cells in Selected PGC=16
Selected VOBID=None
Number of Cells in Selected VOB=None
[Demux]
Number of Video Packs=1741296
Number of Audio Packs=146451
Number of Subs Packs=460
Number of Nav Packs=11515
Number of Pad Packs=0
Number of Unkn Packs=0
[Audio Streams]
Audio_1=0x80
Audio_2=None
Audio_3=None
Audio_4=None
Audio_5=None
Audio_6=None
Audio_7=None
Audio_8=None
[Audio Delays]
Audio_1=0
[Subs Streams]
Subs_01=0x20
Subs_02=None


If you think it may be useful for fixing the problem, I may provide all of the necessary related info...

Taking the opportunity for stating once more the biggest appreciation for your work on the excellent applications you have made available to all of us.

Cheers,
SD

Edit: Checking for the differences, just concerning the first cell of the title, it seems that PgcDemux did not flush out properly the last ac3 packet; hope the attached picture is explaining what I mean...

[img=http://img131.echo.cx/img131/784/image10pd.th.gif] (http://img131.echo.cx/my.php?image=image10pd.gif)

Edit2: While being in the topic... Noticing that also PgcDemux is not "Esc key friendly"... :cool:

[Zeul]

@Jsoto
Works now as planned. Thanks very much. Zeul

[jsoto]

@SD
Ooops. Seems there is more than one bug inside... I'll look into it.

jsoto

[scraper]

hello again,

Just for the record: There was something wrong with the ifo, but a get vts sectors solved that. After doing a mock strip, the problem's still there, no change in the info found by delaycut.

Version 1.2.0.2 works like a charm, though.

If you need any extra info i'd be happy to oblige.

Greets, JP

[jsoto]

@SD & scraper
I was unable to reproduce the problems, probably because I didn't try hard enough, because I found something wrong in the audio extracting code

Could you please check next beta and let me know?
http://jsoto.posunplugged.com/temp/PgcDemux_1204b1.zip

jsoto
BTW, you can safely hit "Esc" now...

[Sir Didymus]

Originally posted by jsoto
...BTW, you can safely hit "Esc" now...

Cool!!! ;)

Well, just testing the 1204b1...

1. The logging is now correct (1204b1 and 1202 coherent).
2. The demuxed m2v is correct.
3. The demuxed sup file (just one subpicture) is correct.
4. The demuxed audio file is not correct: the first byte of the second audio packet in the vob file is missed in the stream demuxed with release 1204b1. See the attached picture for reference:

http://img215.echo.cx/img215/5527/image15ic.th.gif (http://img215.echo.cx/my.php?image=image15ic.gif)

ASAP I will send to you, via PM, some further detail on the subject...

Cheers,
SD

[jsoto]

Weird! Seems there is some bug inside... Sorry, I should have done more tests before output the beta..

jsoto

[jsoto]

Found an uninitialized variable in audio extacting code.., so the results are unpredictible in 1.2.04b1

EDIT:
@all
1203 has some bugs extracting the audio and 1204b1 still has one. Please use 1202 in the meantime.

http://jsoto.posunplugged.com/tools/PgcDemux_1202_exe.zip

jsoto

[jsoto]

Vers 1.2.0.4 (19-04-2005)
- BugFix: Demuxing audio was completely broken in 1.2.0.3 (Sorry )
- Added: Confirmation dialog when quiting, except in the case of using Quit button

jsoto

[scraper]

I can't wait to get home tonight ;)

[scraper]

Hi jsoto,

Works like a charm now!
And man, was i glad to see the "include end time"-option ;)

Thanks for this very handy tool

JP

[jsoto]

Good!.
I'm a little bit busy at work now and cannot test it too much....

jsoto

[candela]

When demuxing (by cell) with PGCDemux I seem to be getting a different delay on the audio than DVDDecrypter (or Smartripper). Also a binary compare shows the audio files to be exactly the same but the video files have 2/3 bytes different (around the 5C offset I believe). Is this normal and does this have anything to do with the delay? Which delay is correct?

[mpucoder]

PGCDemux calculates the delay properly for remultiplexing the audio and video directly, or with the newer avisynth programs. DVDDecrypter and SmartRipper calculate the delay for the old dvd2avi which dropped video frames.
The vidoe bytes that are different are probably the gop timecode. Since there are no fixed offsets in mpg that's only a guess. Look for the header preceeding the bytes that are different, it will be 00 00 01 xx - the xx will tell you what header you are looking at. B8 is the gop header, which contains a timecode. Some rippers give you the option to reset the timecode to start at 00:00:00.00

[candela]

Thanks. It's indeed the timecode. If i don't let dvddecrypter reset the timecode the files are identical.

[jsoto]

@mpucoder
Thanks for the clarifications.
jsoto

[Sajan]

@jsoto
1. With PgcDemux I can demux only 1 PGC or 1 VID or 1 cell. Sometimes I need to demux some part of PGC (for example, 1-12 cells of 14). Can you make it like in ReJig?
2. Also, it would be usefull to allow choose what audio/subtitle track to demux.
3. When I demuxed PGC and then muxed it with another .m2v by IfoEdit, in reauthored DVD subtitles wheren't visible. DVD player found subtitles, I can make them visible or not, but actually they haven't made visible. When I demuxed & muxed DVD with ReJig - all is right. Binary compare showed that .sup is different.
4. Do you plan any kind of "PgcMux"?

Also, when I mux DVD with IfoEdit, if AC3 have more duration than video - in the resulting DVD after video ends it still plays the sound. Can anybody advice program that can cut sound/subtitles according to the video stream?

[CoNS]

Do you plan any kind of "PgcMux"?If you're after a good program to mux it all back together, then I can highly recommend MuxMan by MPUCoder as a very good alternative to IfoEdit and ReJig...

[jsoto]

1. With PgcDemux I can demux only 1 PGC or 1 VID or 1 cell. Sometimes I need to demux some part of PGC (for example, 1-12 cells of 14). Can you make it like in ReJig?No, I've no plans to do this. You can cut your PGC before....
2. Also, it would be usefull to allow choose what audio/subtitle track to demux.
I do not think so. In terms of saving disk space, Subs and audios are not so big, and in terms of speed the effect of demux only part of the streams is minimum.
3. When I demuxed PGC and then muxed it with another .m2v by IfoEdit, in reauthored DVD subtitles wheren't visible. DVD player found subtitles, I can make them visible or not, but actually they haven't made visible. When I demuxed & muxed DVD with ReJig - all is right. Binary compare showed that .sup is different.Mmmm, there are many possible reasons to do not show the subs (i.e, if you change the AR of the m2v and do not change the stream number in IFO, the colors, etc). I've never found a problem here...couild you describe in detail what are you doing, please?.

4. Do you plan any kind of "PgcMux"?God!, no. (mainly because I do not have the knowledge to do it). Use Muxman instead.

jsoto

[Sajan]

Mmmm... I understand... So, without being able to choose set of cells to demux I would like to demux PGC with ReJig and use PgcDemux to generate CellTimes.txt only. And my strange problem with subtitles will dissapear itself:) Thanks for reply.

[2COOL]

@jsoto

Request for a future project when you're taking a break from VobBlanker.

In VB, we can cut VOBs. I was thinking about how that could also be implemented into PgcDemux. Say, I wanted to demux a PGC but wanted to cut out the last cell first, since it's a blank. Just wanted to automate things quicker.

[jsoto]

Noted, but I have some ideas in mind...

jsoto

[Sir Didymus]

Noted, but I have some ideas in mind...

jsoto

Ideas ? Tell me, tell me... Nobody will know about... :cool:

[zacoz]

Yeah we promise not to look :p

Well not with both eyes at once anyway ;)

[jsoto]

No, no, don't get me wrong, nothing really impressive....only a few additional features in VobBlanker, like split cell.

jsoto

[Sir Didymus]

Hi Jsoto - well, just in case you have some "spare time"... :cool:
want to bring to your attention this thread:

http://forum.doom9.org/showthread.php?t=102383

The situation has been reported for a totally unprocessed title...

It happened to me too, in a couple of plain situations, and it is almost frequent when manually removing some protections in Sony titles.

The problem is that the reported A/V delay is "none" for all of the audio strams, but actually audio is present.

The radix of the trouble seems that in a given single PGC there may be present SCR discontinuities. This seems perfectly compliant, since VID changes and SCR discontinuities may be present in a title for many valid reasons, so the A/V delay in a given PGC may change during the PGC playback. Right ?

So do you think it should be possible to report (in the log file ?) the actual A/V delay every time a SCR discontinuity is detected ?

Cheers,
SD

[jsoto]

The radix of the trouble seems that in a given single PGC there may be present SCR discontinuities. This seems perfectly compliant, since VID changes and SCR discontinuities may be present in a title for many valid reasons, so the A/V delay in a given PGC may change during the PGC playback. Right ?
Right. You have to demux by VOBID in this case.
Well, I can add the option to detect SCR discontinuities (useful for blank cells detection), but I think you can have a non seamless playback without a SCR discontinuity.....
jsoto

[mpucoder]

So do you think it should be possible to report (in the log file ?) the actual A/V delay every time a SCR discontinuity is detected ?

Cheers,
SD
There are two ways to join vobs together, which is where you should be seeing SCR discontinuities, seamlessly or non-seamlessly.
In a non-seamless joint all the audio in the first VOBU belongs to that vob, and can be detected, without consulting the PGC, by checking the initial pts values of all streams. They will match vobu_s_ptm in a non-seamless joint, and the delay is zero. (when will the audio delay myth die?)

In a seamless joint there will be audio with pts values < vobu_s_ptm. These belong to the previous vob, and should not be demuxed with this vob (but should be demuxed with the previous - demuxing must look at the vobu following the end of a vob). This is where the negative delays come in. The only decision here is to which vob do the audio frames that cross vobu_s_ptm belong. Multiplexers such as Scenarist and Muxman use the minimum error method to determine when to switch audio during a seamless joint. This means the absolute value of the misalignment (assuming the audio is meant to be exactly in sync with the video) caused by the inability to pause or gap the audio for resync, is <= half the duration of one audio frame. So an audio frame that spans vobs belongs to the previous vob if (pts + duration/2) < vobu_s_ptm. From there you can either propagate the error by calculating a delay that will cause the next multiplexer to duplicate the misalignment, even in a non-seamless joint, or realize that the delay should be zero.
For seamless joints Muxman ignores the delay values. And if the original was demuxed by the method I explained above, the remux will be an exact replica.

[Sir Didymus]

You have to demux by VOBID in this case...


Yes, but demuxing by VOB ID is not always a solution:
I have some examples where the A/V delay (as reported by PgcDemux) is none for all of the VOB ID in a given title. This happen due to the presence of some blank cells without audio at the beginning of each one of the VOB...


Well, I can add the option to detect SCR discontinuities (useful for blank cells detection), but I think you can have a non seamless playback without a SCR discontinuity...


That's very kind and it will be absolutely appreciated...
Anyway let me focus a little more the reason and the content of the request...
The idea is not just to facilitate the detection (with the purpose of removal) of blank cells, nor to remove the SCR discontinuities [if they are present they should be there for some valid reason]...

It could be instead relevant to know [maybe in the log file ?] that in a given point of the demuxed streams the demuxer detected a cell non seamless joined to the previos. When this condition happen, it is IMHO important to let the user know:
- if in the cell some audio streams exist, and in case it does,
- the relative A/V delay, (it should be the differece between start presentation time of the first VOBU in the cell and the PTS value(s) of the first audio packet for each of the audio streams...)

@mpucoder
Thanks for your clarifications, I really understand it could be somehow boring to repeat some explainations on arguments already widely covered and discussed elsewere...

Your description of the situation related to the seamless joint is understood; what is not still clear to me, is what happen, in case of non seamless joint, in both of the situations when the first VOBU have audio, and when it have no audio.


In a non-seamless joint all the audio in the first VOBU belongs to that vob, and can be detected, without consulting the PGC, by checking the initial pts values of all streams.
They will match vobu_s_ptm in a non-seamless joint, and the delay is zero.
(when will the audio delay myth die?)


OK! - Let's destroy this stupid myth... :-)

Well, seriously... could you expand this a little bit more - suspect me simply not understanding what you mean... ?

Are you stating that in a seamless joint the pts of the first audio packet should be necessarily equal to vobu_s_ptm, and this condition should happen for all of the audio streams ?

So is it illegal to have no audio in the first VOBU of such a cell ?

And finally, when blanking a non seamless joined cell, by substituting its A/V content with some black I frames, without any audio content in it, are we introducing incoherences with this way of proceed ?

[mpucoder]

Maybe this will help. Vobs joined non-seamlessly are autonomous, that is there is nothing from one vob in the other. Each can stand on its own as a properly multiplexed video object. The audio from the first vob must end at the same time or earlier than the video. The player most likely will pause while it finishes one vob and starts filling the buffers with the next, hence non-seamless.

Seamless joints, due to the much shorter delay in the audio path from disk to decoder than the video, must put some of the audio from the first vob into the beginning of the second. This maintains the multiplex as if there were no joint at all, very similar to how cells are joined, and the player can continue without pause.

The audio delays exist for two reasons. The first has been corrected by Neuron2, and that was caused by dvd2avi not understanding the structure of a closed gop. That program dropped the B frames that display prior to the I frame, and so introduced a 2 frame misalignment, 67ms for NTSC, 80ms for PAL,

But the second reason persists today, and that is caused by the demuxing of seamless vob joints and cells. The demuxers, even PgcDemux, start demuxing with the first audio pack assuming that the first vobu is autonomous and contains nothing that does not belong logically to the vob. But in a seamless joint the first vobu contains the trailing audio of the previous vob. Since a typical AC3 seamless joint will have packs of audio with pts values around 12000 (all times in clock ticks), and the video pts anywhere feom 20000 to 37000, the delays are reported in a range of about -88ms to -280ms. These 88 to 280 ms of audio belong to the previous vob.
The result is that the first vob's audio runs out early, and the second gets a large negative dely (plus running out early if the next joint is seamless. No multiplexer can put this back together, and most, because there is insufficient audio, will refuse to make a seamless joint.

When I was testing MuxMan for seamless joints (version 0.17) I had to use a binary editor to move audio data from one file to the other to correct for this. 0.17 now has an alternative method where you demux the entire audio and specify in and out points (Start and Run Length) of the audio for each vob.

[mpucoder]

what is not still clear to me, is what happen, in case of non seamless joint, in both of the situations when the first VOBU have audio, and when it have no audio.
In a non-seamless joint, with or without audio in the previous vob, the next vob starts fresh, as if there were no vob before it. In fact you can join vobs from different multiplexers non-seamlessly.

Are you stating that in a seamless joint the pts of the first audio packet should be necessarily equal to vobu_s_ptm, and this condition should happen for all of the audio streams ?
Just the opposite, a non-seamless joint will have the audio (and video) begin at vobu_s_ptm.

So is it illegal to have no audio in the first VOBU of such a cell ?
I'm assuming you mean a seamless joint. It should have the trailing audio of the previous vob. It is possible to seamlessly join vobs with audio in one vob but not the other. In the case of audio in the first and no audio in the second only the first vobu after the joint will contain a little audio. In the opposite situation the second vobu will look very much like a non-seamless.

Another thing that must happen in a seamless joint, and is a telltale sign, is that no audio frames span the joint. That is the audio in the previous vob will most likely require padding as it cannot contain a partial audio frame. And the first audio in the new vob will start at an audio frame header (the offset to which will be 1)

I have been talking mainly about the audio as demuxers need to fix the way they work for audio. But in all cases the SCR and video delay are affected by the type of joint. The SCR is reset in both cases, but what it represents is different. In a non-seamless joint all time values are reset, and the decode starts fresh. In a seamless joint the SCR value of 0 is handled as if it were the next SCR value from the previous vob, and a difference is calculated. This difference value then affects ptm and pts values, so that they can be adjusted by the same amount. Here is an example:
The last SCR value of the vob preceding the joint is 5390713 and the vob's e_ptm is 5424651. Now in the next vob we must proceed as if scr 0 represents 5390713+147 (the transfer time of one pack) = 5390860. Since in all seamless joints (vob or cell) the vobu_s_ptm of one vobu is equivalent to the vobu_e_ptm of the previous our new vob's starting ptm must be equivalent to 5424651 but adjusted by the difference value, so 5424651 - 5390860 = 33791. This will be the new vobu_s_ptm, and the pts of the video.

And finally, when blanking a non seamless joined cell, by substituting its A/V content with some black I frames, without any audio content in it, are we introducing incoherences with this way of proceed ? No, as stated vobs joined non-seamlessly are independant of each other.

[Sir Didymus]

I see.


...Just the opposite, a non-seamless joint will have the audio (and video) begin at vobu_s_ptm.

This is the part I was looking for, and it is what I supposed. For a stupid typing mistake I wrote:
"Are you stating that in a seamless joint the pts of the first audio packet should be equal to vobu_s_ptm ..."
instead of "Are you stating that in a non seamless joint the pts of the"

But even with this misunderstanding, your comments are definitely clarifying.

I think I understand what is going on in case of seamless joints.

What I am still interested in is the presence of relevant holes (audio gaps) in a given program chain, created by the practice of blanking some unwanted cells from the PGCs.

When you say:

a non-seamless joint will have the audio (and video) begin at vobu_s_ptm.

this condition is clear, since the new vob is a totally fresh one. But exactely for this reason it may legally happen that the fresh vobu have no audio at all. Right ?

In this situation [presence of an audio gap at the beginning of a new vob or immediately after a SCR discontinuity] I just wanted to understand what a demuxing application should do for decoding the audio stream as a whole from the PGC, while keeping the audio in synch with the video.

Is this possible at all or maybe the only possibility is to decode the audio in chunks ?

Edit: forgot to thank you for the time you are putting into your appreciated and very useful "enlightening posts"...

[mpucoder]

The best thing for a demuxer to do if it encounters a gap in the audio is to inform the user, and suggest demuxing by VobID.

[jsoto]

Well, I knew pgcdemux was not doing everything OK when demuxing by VID or single-Cell, but I really don't have all the related knowledge... So, first of all, thanks mpucoder for sharing it with us.

So, what should be changed in pgcdemux?
If I understood well, this is the situation:

1.- Demuxing by PGC:
- Check on every Vob change if it is a seamless or a non-seamless joint. If it is a non-seamless, warn the user and recommend demuxing by VobID.
Question 1: Which will be better: trust the IFO (PGC playback table) or the Vob (using the algorithm of zero delay in audio, i.e.)

2.- Demuxing by VobID:
- Check if the previous or next Vob have a seamless or a non-seamless joint. I'm assuming previous/next in the file layout, not in the PGC position
Question 2: A seamless joint has to be always with the next VobID? , i.e. is it legit a seamless joint between VID=1 and VID=3 ? Seems the answer is yes in a multiangle/multistory..., so how to determine which one is "the next" or "the previous"? Note in a multiPGC VTS one Vob can be joint to two different vobs (in two different PGCs)

If the previous Vob is a seamless-joint...
Question3: Should pgcDemux discard the audio packs until the minimum error in terms of delay ones?

If the next Vob is a seamless-joint..
Question4: Should pgcDemux demux the audio packs in the next Vob until the minimum error in terms of delay?.
Question5: Again, how to determine "the next"? What to do in the case of a branch (a multistory , i.e., VobID=1 is splited into two branches, VobId=2 and VobID=3)

3.- Demuxing by CellID:
Mmmm, seems identical to VobID., taking into account all cells in the same VobID are seamless between them

jsoto

[Sir Didymus]

I'd really prefere it is a person ( - hem... THE person ? - ) with a much better knowledge on the subject to give some further contribution...

Anyway, this is my undestanding - and please forgive me in case it turns out, as it may easily happen, of me posting some silly arguments...

1.- Demuxing by PGC:
- IMHO the check of non-seamless joint should be performed at every cell. Look at the scenario where you use VobBlanker for blanking the first cell of a movie, substituting the whole cell with a single I frame, or another scenario where the first cell - production logo ? - is authored by purpose without audio. Here a non-seamless joint is generated and the demuxer looses the synch between audio and video. Maybe instead of suggesting to demux by VOB ID (it would not permit to recover the synch), it would be useful to place, in the log file, the information of the whole cell duration, in case it have no audio. Regard what to thrust, probably it would be nice to use the IFO for determining the playback order and to thrust the VOB (pts of audio and video packs) for calculating the time relationship between audio and video...


2.- Demuxing by VobID:
- Your Question 2 is crucial. This is maybe the reason why the only proper way of demuxing something by VOB ID is also to follow the PGC, for collecting the right cell sequence. Maybe in this case the GUI should be changed in order to get the PGC first and then to get the Vob ID and the cell sequence from there. The same should be made - if possible - for demuxing by cell-id: first it should be defined by the user the PGC, then the VOB-id, then the Cell-id...

- Your Question3: If the previous Vob is a seamless-joint AND the application is demuxing by VOB ID, the demuxer should discard the initial audio packs belonging to the previous VOB. In my understanding, if in the initial cell of the VOB some audio packs have pts which is less than the VOBU start time, these are by sure not belonging to the VOB, so they should be discarded...

- Regarding your Question4: IMHO, yes. For the same reason of the previous question - as perfectly explained by mpucoder - in demuxing by VOB ID, the search of the audio for the last cell in the VOB should extend to the following VOB in order to collect the last audio packs belonging to the VOB.

Question5: Same as Q2... by demuxing the VOB in a given PGC.

------------------------------------------------------------
To everybody reading - hey people, don't want you wrongly
assume from the above discussion, that PgcDemux have bugs.
It is the best demuxer all around. That's all.
The discussion is about improvements, and contributions on
the matter are welcome...
------------------------------------------------------------

Cheers,
SD

Edit: maybe, in the demuxing by PGC and VOBID, a possible solution in order to let the user cope with "cells without audio" is simply to have an option for demuxing the audio in chunks. When a cell without audio is encountered, a new chunk is started. This way, together with other applications like your "silence" and/or "delay cut" it should be possible to put together a new audio asset matching with the demuxed video... Well, let's see..

[mpucoder]

Well, I knew pgcdemux was not doing everything OK when demuxing by VID or single-Cell, but I really don't have all the related knowledge... So, first of all, thanks mpucoder for sharing it with us.

So, what should be changed in pgcdemux?
If I understood well, this is the situation:

1.- Demuxing by PGC:
- Check on every Vob change if it is a seamless or a non-seamless joint. If it is a non-seamless, warn the user and recommend demuxing by VobID.
Only if it appears that the audio will cause sync problems later on. Each vob should have sufficient audio for its video, so that the next vob starts within half an audio frame. Cases where a vob has no audio, or is more than half an audio frame short of the video duration, will cause sync problems if not demuxed by VobID. The last vob can be as short as it wants, as it will not affect any following vob.

Question 1: Which will be better: trust the IFO (PGC playback table) or the Vob (using the algorithm of zero delay in audio, i.e.) I would not trust the ifo, and in any case it is a matter of video duration vs audio duration.
2.- Demuxing by VobID:
- Check if the previous or next Vob have a seamless or a non-seamless joint. I'm assuming previous/next in the file layout, not in the PGC position
Question 2: A seamless joint has to be always with the next VobID? , i.e. is it legit a seamless joint between VID=1 and VID=3 ? Seems the answer is yes in a multiangle/multistory..., so how to determine which one is "the next" or "the previous"? Note in a multiPGC VTS one Vob can be joint to two different vobs (in two different PGCs)
You are correct, it is possible to have seamless joints between vobs which are not contiguous. The best way to determine this is to map out the playback flow of all the PGCs. Not an easy thing to do, but a huge feather in the cap of the demuxer which can. There are only 2 ways multiple paths will be seen, either by using cell blocks (they will be marked as an ILVU block) and multiple PGCs - eg PGC1 uses VobID 1, 2, 4 and PGC2 uses 1, 3, 4. Here both 2 and 3 are seamlessly joined to the tail end of 1. Either 2 or 3 can be used to retrieve the last few frames of 1. If you have trouble finding test cases MuxMan 0.17, which I believe you have acces to, can create multi-story vobs now. That would give you a controlled environment - make a multi-story from A/V streams, demux and compare.

If the previous Vob is a seamless-joint...
Question3: Should pgcDemux discard the audio packs until the minimum error in terms of delay ones?yes, they belong to the previous logical vob

If the next Vob is a seamless-joint..
Question4: Should pgcDemux demux the audio packs in the next Vob until the minimum error in terms of delay?.yes, after determining it is the correct vob

Question5: Again, how to determine "the next"? What to do in the case of a branch (a multistory , i.e., VobID=1 is splited into two branches, VobId=2 and VobID=3)I think I covered that above.

3.- Demuxing by CellID:
Mmmm, seems identical to VobID., taking into account all cells in the same VobID are seamless between themCells within a vob are joined in a different kind of seamless joint that is no different than any two adjacent VOBUs - ie cells can be made anywhere without remuxing (an important feature for editing DVD-VR recordings). However, you are right, audio from one cell will be found at the start of the next. Here, as in seamless vob joints, pts can be your friend. Every VOBU contains a starting ptm (vobu_s_ptm) that can be used to determine to which cell an audio frame belongs.

[Zeul]

Now thats an answer :D

[mpucoder]

Now that I have more time I read SD's post, and it raises an interesting question. My experience is from the authoring point of view, and the specs (as best we know them). Is it possible with VobBlanker or other tools to replace a cell that had audio with one with no audio? This is contrary to what an authoring program would do, changes in the audio layout can only occur at the vob level. If it is true, then that situation must also be detected and addressed, as SD pointed out. The simplest way I can think of is to check for gaps during the demux itself. This can be done by checking the pts of each pack, which should match exactly the previous pts + (number_of_frame_headers * audio_frame_duration)
Audio frame durations are:
AC3 2880
DTS 960
LPCM 150
mpeg 2160
Note that mpeg audio is trickier as it is does not use the private stream and therefore has no DVD specific header to give you the frame count, and vbr is allowed (so parsing is probably the only reliable way to count frames).

If, on the other hand, the cell is replaced with a still of the same duration as the old motion video, there is no problem. PgcDemux need not be aware of phantom frames (Philips term for a still held by means of the vobu_se_ptm and sequence_end) since there are 2 reliable places to get the video duration of a vob without examaning the video itself. One is vobu_e_ptm of the last NAV pack, which should match vob_v_e_ptm (offset 0x437) of all NAV packs in the vob.
And there is an interesting area following vob_v_e_ptm which handles audio gaps - these should not be a concern, though. Audio gaps can occur ONLY at seamless vob joints, and are used to adjust for the duration differences in multiple paths. Anytime there are multiple paths a different kind of demux will be needed. It may be possible to demux the primary path as a whole, but the alternate parts need to be demuxed seperately, and by VobID. This is how most multi-angle and multi-story DVDs are authored, as a contigous main movie + angles/alternate scenes.

[mpucoder]

------------------------------------------------------------
To everybody reading - hey people, don't want you wrongly
assume from the above discussion, that PgcDemux have bugs.
It is the best demuxer all around. That's all.
The discussion is about improvements, and contributions on
the matter are welcome...
------------------------------------------------------------
I totally agree, PgcDemux is the best demuxer I've used. But now we are working to make it even better by handling the tricky DVDs that result from multi-angle, multi-story, and copy protection schemes.

[jsoto]

Hi all


------------------------------------------------------------
To everybody reading - hey people, don't want you wrongly
assume from the above discussion, that PgcDemux have bugs.
It is the best demuxer all around. That's all.
The discussion is about improvements, and contributions on
the matter are welcome...
------------------------------------------------------------
I totally agree, PgcDemux is the best demuxer I've used. But now we are working to make it even better by handling the tricky DVDs that result from multi-angle, multi-story, and copy protection schemes.

Thanks. As you know, I had valuable help during the development ;)

Is it possible with VobBlanker or other tools to replace a cell that had audio with one with no audio? This is contrary to .... Yes it is possible, although not really recommended... Also it is possible to cut away part of a cell in a "brute" way. Both things can cause gap problems. Cuting is recomended only at the end or at the begining of the PGC, but ....
So, yes, I'll include some kind of audio gaps detection during the demuxing process.

Note that mpeg audio is trickier as it is does not use the private stream and therefore has no DVD specific header to give you the frame count, and vbr is allowed (so parsing is probably the only reliable way to count frames). I know, but, as in Dolby (32 msec frame) because of the allowed sampling rate is only 48K the frame duration is always 24 msec (2160 tics), isn't it? . But yes, in mpeg, seems parsing is the only way to go.

Well, guys, seems everything is covered and it's time to work on it.

jsoto

[Zeul]

It seems that a couple of numenu users have had a problem when demuxing by cell is required. I have finally managed to replicate the problem. From the GUI cell demux works fine, but from the c/l i can't get it to demux any cell > 1. The c/l i am using is:

-m2v -cid 1 2 -aud -nosub -nolog -menu -nocellt and then the ifo params

-cid 1 1 works, but nothing else.

Probably my useage :D

Zeul

[jsoto]

@Zeul
Mmm, at first view the cli is OK. So seems there is a bug.
I'll look into it.

@all
Do not expect a fast response in pgcDemx development, I'm working now in VobBlanker..

jsoto

[dirio49]

@all
Do not expect a fast response in pgcDemx development, I'm working now in VobBlanker..

jsoto

:thanks:

[jsoto]

It seems that a couple of numenu users have had a problem when demuxing by cell is required. I have finally managed to replicate the problem. From the GUI cell demux works fine, but from the c/l i can't get it to demux any cell > 1.

Try PgcDemux1205 (http://www.videohelp.com/~jsoto/temp/PgcDemux_1205_exe.zip)
(Stupid cut & paste bug in CLI mode demuxing by CID). Nothing more has changed, so I'm not going to announce it as a release....


jsoto

[Zeul]

Thanks jsoto - works perfect from cli now :)

[davemorell]

Hi there'

I would like to know is there a way to open single vob files in pgcdemux without an ifo file??? Because I have to cut out some cells from the original movie, I did this with VobBlanker 2.0.1.0 (extract cells from 25 to 45 into a single vob file, and vb not created an ifo file for this). I can do the same with vStrip 0.8f, but it does not creat an ifo file too.

Is there a way to create an ifo file for vob files? Or are there any other solution to 'cut out' (for example: through an ifo file) the first cells, and then pgcdemux will open it fine?

Greetings'

[r0lZ]

Use IfoEdit's Create IFOs function. See the IfoEdit homepage...

[davemorell]

@ r0lZ : thanks for the tip

Although I had some problems. I cut the cells with VB, with IfoEdit I made the IFO files successfully. Then I loaded into PgcDemux and I started demuxing process. At 40% I got a Finsih OK! message... Strange....

Then I tried DVDReMake and deleted the unnecessary cells. I tried to demux again but it also stopped at 40% with an error message "Error reading input, VOBU Unsynchronized", after a click I got Finish OK message too. I tried vStrip too but IfoEdit could not create an ifo file (not found any VOBU unit message).

Then I tried again, my last hope: dvd decrypter with ifoedit. I successfully made it the first time :) If I'm demuxing the video stream or/and the audio streams to elementary streams and direct streaming the subtitle streams into one vob file and make an IFO file with IfoEdit I had no problem, PgcDemux demuxed the sup or/and audio files fine. BUT! If I direct streaming video+audios+subs into one vob file..... PgcDemux stopped at 47% (not 40% beacuse I just keep two audio not four I think) with Finish OK! message. It's realy strange...

I hope the DD + ifoedit + pgcdemux method 1 will work for me. It will be nice if PgcDemux can make what DD does for me now (chapter/cell/stream selection). I'm wondering why the vStrip method not working, but it's another story :)

Greetings'

[r0lZ]

Hum... Seems it's a problem for jsoto!

[jsoto]

Trying to guess....

IIRC, VobBlanker extracts all the cells in only one big VOB. (Note this is not fully correct, a VOB file should not be higher than 1 GB).

PgcDemux does not support files higher than 2 GB

So, if this is your case....
- Extract the cells with VB in three or four files (splitting the job, selecting just some of the cells), naming them
VTS_01_1.VOB
VTS_01_2.VOB
VTS_01_3.VOB
VTS_01_4.VOB
- Create IFOs with IFOedit
- Run pgcDemux.

jsoto

[davemorell]

You are absolutely right :) I always let the ripping process to make one big vob file. I thought it will be easier for me, and for making the IFO files. It was a mistake, I was afraid of multiple files without an ifo file, and I never had to make this kind of things till today. But now I understand a little bit more how the multiple files work. Thank you for pointing this out :)

Don't yout think about, you can integrate VobBlanker, PgcDemux, DelayCut... into one massive VOB manipulating tool??? Because they are very close to each other? I know it is easier to maintain while they are seperate but if they works fine alone why not put all of them into a big one...maybe someday ;)

Greetings and keep up the good work!

[SlipGun]

Why would pgcdemux output files with a few cells missing in the middle (both the video and audio), when both the celltimes file and the log list all the cells in the PGC? I suspect this has something to do with interleaved cells, but don't know how to correct it.

[jsoto]

@SlipGun
Could you elaborate?. I don't understand well your question...
Does pgcdemux fail in a ILV DVD?
jsoto

[SlipGun]

No, it does not fail. The video stream and audio streams are just shorter than they should be. The DVD is Toy Story 10th Anniversary edition: ~80 minutes long, but the output is only about 70 minutes. I'm not sure which section is missing exactly, but the beginning and end are fine, so it's something in the middle.

[CoNS]

Does the main movie PGC have multiple angles (check if the "Angle" dropdown field in PgcDemux is activated)? If yes, it may be the problem...

[SlipGun]

Yes, it does in the original DVD. Although I stripped angles 2 and 3 with no problem and it plays fine.

[jsoto]

And how do you get 80 min length?
Could you check the duration of the PGC with pgcEdit?. It automatically checks the duration when you opens the PGC. Just load the DVD in pgcEdit and double click on your TTN in the left pane.
jsoto

[SlipGun]

The movie's 1:20:33 in pgcedit. The demuxed m2v is around 1:03:55 in PowerDVD - I don't know if the PowerDVD indicator is reliable.

I want to replace an audio stream, but when I tried doing running the remux (done with Muxman) through VobBlanker I got an error saying some cells would be blanked due to a mismatch. The resulting output was very undersized.

This may not be a pgcdemux problem and I may be doing something wrong, but I can't tell what.

[jsoto]

VobBlanker does not support multiangle...
Are you loading some kind of processed IFOs? May be the stripped angle ones?

jsoto

[SlipGun]

jsoto: I sent you the IFOs as you requested. However, I'm having the same problem again with a non-multiangle DVD. Muxman fails at cell 19 of 20 with the "non-existant scene" error. I have "include end time" unchecked. The demuxed files seem to be the right size (unlike what I earlier thought), so I think something else is the problem.

[jsoto]

I've got the IFOS, but I cannot see anything wrong on them.
Seems you have removed OK the angles and post-processed with FixVTS or VobBlanker.... (renumbering the VCIDs)

The only thing I've found is a small bug in PGCdemux. If the last cell is a multiangle-one, unchecking the "include end time" has no effect, unless you are demuxing the highest angle.

In your second DVD (the non-multiangle one), could you post the exact PGC duration (including the frames) (better the complete cell list with their durations) and the last rows of celltimes.txt?


I'll look into it deeply, but I'm lost...

[jsoto]

Could you check the length of the demuxed audio?. Load the files in delaycut (available in my sites) and you´ll get the duration.

I've reproduced a similar problem using FAT32 and a video file larger than 4 GB. Neither pgcDemux nor MuxMan output any errror/warning, but the video is truncated and the muxed DVD is 4 minutes shorter than the original.

Are you using FAT32?

jsoto

[SlipGun]

Thanks for the update ...

I just found the problem with the non-multiangle DVD.

VobID 1 contains the movie; VobID 2 is just 15 frames of blank video. The original IFO shows cell 1/7 to be 17 minutes long. I used IfoEdit to strip VID 2, and noticed that this value changed from 17 to 10 minutes.

So the running time is only 2:02, not 2:09 (the original DVD plays just fine - but clicking anywhere on the 7 "missing minutes" in PowerDVD's time slider takes me to cell 8).

I assume pgcdemux copies the celltimes from the IFOs, which would explain why Muxman errored out - the celltimes made the movie appear longer than it really is.

After I'd done this, the remux finished okay, as expected.

I tried doing a mock strip without removing VID 2 and noticed that it did not change the times, so this is the only way I know of how to fix the problem. I suspect Toy Story has the same issue - it has a 15-frame VID at the end which I'll try stripping later.

I'm on NTFS, btw.

[jsoto]

Ah! Thanks for the report back.

BTW, VobBlanker, even in keep mode, should recalculate the cell times....

jsoto

[SlipGun]

I went back to Toy Story: ran it through VobBlanker, demuxed, remuxed. The final output plays fine except for the chapter points which are slightly before where they should be. The muxman log shows:

Starting scene Segment_1_scn2 at 00:01:30:00, requested for 00:01:29:29

... and so on for all the scenes. Is there a workaround?

[jsoto]

Did you reencode the video?
If yes, you need to fix the chapters in the encoder, to be sure an I-Frame will be there, and to guarantee a closed GOP at the begining of the cell.

If not, the only thing I can imagine is the celltimes in IFO are not correct. Run vobblanker in keep mode or do a IFOedit's mock strip. Both procedures will recalculate the celltimes.

BTW, we are running out of topic... May be it is better to open a new thread.

jsoto

[CoNS]

jsoto, I'm trying to demux a main movie in order to add some custom made subtitles. The VTS containing the main movie has three PGCs.

When I check A/V delay in PgcDemux delay it says 0 ms. for all three PGCs, but when I demux PGC 2, the PgcDemux log file says Audio_1=35840 (see entire log file below).

Also, MuxMan and IfoEdit both choke on the demuxed files when I try to mux/author a new DVD.

Any idea what could be wrong?

[General]
Total Number of PGCs in Titles=3
Total Number of PGCs in Menus=1
Total Number of VobIDs in Titles=6
Total Number of VobIDs in Menus=1
Total Number of Cells in Titles=26
Total Number of Cells in Menus=1
Demuxing Mode=by PGC
Demuxing Domain=Titles
Total Number of Frames=294636
Selected PGC=2
Number of Cells in Selected PGC=23
Selected VOBID=None
Number of Cells in Selected VOB=None
[Demux]
Number of Video Packs=1895988
Number of Audio Packs=272928
Number of Subs Packs=0
Number of Nav Packs=19629
Number of Pad Packs=0
Number of Unkn Packs=0
[Audio Streams]
Audio_1=0x80
Audio_2=None
Audio_3=None
Audio_4=None
Audio_5=None
Audio_6=None
Audio_7=None
Audio_8=None
[Audio Delays]
Audio_1=35840
[Subs Streams]
Subs_01=None
Subs_02=None
Subs_03=None
Subs_04=None
Subs_05=None
Subs_06=None
Subs_07=None
Subs_08=None
Subs_09=None
Subs_10=None
Subs_11=None
Subs_12=None
Subs_13=None
Subs_14=None
Subs_15=None
Subs_16=None
Subs_17=None
Subs_18=None
Subs_19=None
Subs_20=None
Subs_21=None
Subs_22=None
Subs_23=None
Subs_24=None
Subs_25=None
Subs_26=None
Subs_27=None
Subs_28=None
Subs_29=None
Subs_30=None
Subs_31=None
Subs_32=None

[jsoto]

Really strange.... I'm using the same code to get the delay fro the button and when demuxing... :confused: :confused: Seems there is a bug, but I think it is related with someting "special" in your VOB/IFO...

Could you send me the IFO and the first cell of the PGC #2 ? (At least the first packs of the cell, including the first audio)
(i.e. extract the cell with VobBlanker, and cut it with Cutfile)
jesus_soto_viso at terra dot es

jsoto

[CoNS]

I'm experiencing something fishy with the a/v delay when demuxing a certain DVD with PgcDemux, and muxing with MuxMan.

I'm demuxing the main movie, which is located in VTS_02, PGC #2. PgcDemux' "Check a/v delay" button (and the log file) tells me there's a delay of -224 ms. So, when I mux everything back together (with a new custom made SUP file), I type in a delay of -224 ms in MuxMan...

BUT when I check the a/v delay of the newly muxed main movie PGC in PgcDemux, it says that there's no a/v delay!?! :confused: Anyone has a clue why?

[bigotti5]

Muxman starts audio never more than 1200 SCR ticks before video so muxman cuts off ac3 frames if you specify delays > -13ms.
One ac3 frame is 32 ms long so in your case 7 frames (7 *32 =224) are dropped and results in 0ms delay.
If you specify -226 ms you will get -2 ms delay, -222 ms will result in +2 ms.

[CoNS]

Ah, thanks for explaining, bigotti5. Makes sense.

[Annatasia]

I have a problem too. Mine AC 03 is out of sync. How can I fix this?

PgcDemux given.

Audio_1: 0x80 --> -1msec

I need to put a good delay in muxman, can someone help me?

thnx

[blutach]

Muxman should accept -1, although this is a strange number.

Regards

[manono]

Find out the amount of the delay and either enter it in Muxman (up to +/- 300ms) or get rid of it entirely using DelayCut. To find the delay I play a VOB using Media Player Classic Home Cinema (although other players also have the ability to adjust the delay) and use the +/- buttons on the keyboard to change the delay on the fly.

http://www.videohelp.com/tools/Media_Player_Classic_Home_Cinema

[xekon]

One quick question about PgcDemux. when you extract the streams from a vob you lose the PTS timestamps.

When you use PgcDemux to Demux "by VOB id" and you select the "Create a PGC VOB" for output. Does it demux the streams and put them into a VOB with new PTS timestamps, or are the timestamps saved/adjusted from the original vob timestamps?