PgcDemux 1.2.0.4 is out [Archive] - Page 2

jsoto

8th March 2005, 01:37

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

19th March 2005, 11:18

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

19th March 2005, 11:45

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

19th March 2005, 13:27

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

25th March 2005, 09:43

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

25th March 2005, 20:20

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

26th March 2005, 06:25

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

26th March 2005, 08:41

@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

28th March 2005, 01:49

@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

28th March 2005, 01:57

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

28th March 2005, 02:09

@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

7th April 2005, 09:42

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

7th April 2005, 10:11

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

7th April 2005, 14:38

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

11th April 2005, 00:26

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

11th April 2005, 15:29

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

11th April 2005, 18:24

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

11th April 2005, 19:06

Ah, ok.

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

jsoto

11th April 2005, 22:27

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

13th April 2005, 22:00

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

13th April 2005, 23:32

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

14th April 2005, 09:12

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

Sir Didymus

14th April 2005, 10:35

@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

14th April 2005, 12:41

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

jsoto

14th April 2005, 18:06

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

jsoto

scraper

14th April 2005, 19:12

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

14th April 2005, 22:10

@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

15th April 2005, 09:54

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

15th April 2005, 21:58

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

jsoto

jsoto

15th April 2005, 22:21

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

19th April 2005, 23:07

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

20th April 2005, 08:50

I can't wait to get home tonight ;)

scraper

21st April 2005, 20:01

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

21st April 2005, 22:58

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

jsoto

candela

14th June 2005, 07:53

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

14th June 2005, 12:19

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

14th June 2005, 19:04

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

jsoto

14th June 2005, 22:22

@mpucoder
Thanks for the clarifications.
jsoto

Sajan

22nd June 2005, 14:39

@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

22nd June 2005, 16:58

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

23rd June 2005, 00:33

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