PgcEdit v7 discussion thread

[r0lZ]

PgcEdit takes everything that is in the parent of VIDEO_TS to build the compilation. Therefore, if you don't want to burn DVD-ROM files, you have to remove them, or move the VIDEO_TS folder in another, new folder.

The correct structure is:
<DVD folder, the root folder of your compilation. That's the folder that is burned.>
---- <VIDEO_TS folder, with the DVD-VIDEO files>
---- <AUDIO_TS folder, created automatically by PgcEdit if it doesn't exists>
---- <JACKET_P folder, optional, with jacket pictures>
---- <optional DVD-ROM files and folders>

Note that the files and folders with "backup" or "copy of" in their names are excluded automatically from the compilation.

[r0lZ]

@erdoke

I've analysed your IFOs, and everything seems normal. However, the size of the VOB files of VTS 1 are in MB in the screenshot I have received, and it's not accurate enough to be sure. Could you send me the size of VTS_01_0.VOB to VTS_01_5.VOB expressed in KB or bytes? Thanks.

Also, given the values in the IFOs, the 32K gap option was not checked when you tried to burn the DVD. Could you confirm?

[erdoke]

Directory of L:\DVDW\VIDEO_TS

2006.05.24. 19:52 <DIR> .
2006.05.24. 19:52 <DIR> ..
2006.05.24. 19:52 0 lista.txt
2006.05.24. 12:58 <DIR> PgcEdit_backup
2006.05.24. 12:59 18˙432 VIDEO_TS.BUP
2006.05.24. 12:59 18˙432 VIDEO_TS.IFO
2006.05.24. 12:59 112˙640 VTS_01_0.BUP
2006.05.24. 12:59 112˙640 VTS_01_0.IFO
2006.05.24. 09:41 74˙852˙352 VTS_01_0.VOB
2006.05.24. 09:57 1˙073˙739˙776 VTS_01_1.VOB
2006.05.24. 09:58 1˙073˙739˙776 VTS_01_2.VOB
2006.05.24. 09:59 1˙073˙739˙776 VTS_01_3.VOB
2006.05.24. 09:59 1˙073˙739˙776 VTS_01_4.VOB
2006.05.24. 09:59 300˙003˙328 VTS_01_5.VOB
2006.05.24. 12:59 18˙432 VTS_02_0.BUP
2006.05.24. 12:59 18˙432 VTS_02_0.IFO
2006.05.24. 10:27 10˙240 VTS_02_0.VOB
2006.05.24. 10:27 10˙240 VTS_02_1.VOB
2006.05.24. 12:59 18˙432 VTS_03_0.BUP
2006.05.24. 12:59 18˙432 VTS_03_0.IFO
2006.05.24. 09:44 10˙240 VTS_03_0.VOB
2006.05.24. 09:44 10˙240 VTS_03_1.VOB
19 File(s) 4˙670˙191˙616 bytes

Since I've run into playback problems with certain standalones, the 32K gap function is always turned off.
I don't burn my ISO files automatically, usually burn them later with ImgBurn. This was the case this time too, only wanted to create the image file.

[odbo2005]

PgcEdit add a "Play All" pgc,the seek bar can't work in WinDVD.
Scenarist add a "Play All" pgc,the seek bar work fine in WinDVD.

I check the vts ifo in IfoEdit,
PgcEdit VTS_TMAPTI number of VTS_TMAPs is "5",
Scenarist VTS_TMAPTI number of VTS_TMAPs is "6",
It's mean PgcEdit add a "Play All" pgc,but did'nt add it to VTS
time map table?

[Grave]

i have encountered same error once before, i solved it by adding blank cells to problematic vob increasing its size to 40k
the 32k gap worked too but i have it turned off too because of playback issues

[bigotti5]

@odbo2005

Creating TMAPS is in work - see http://forum.doom9.org/showthread.php?t=111436

Create a TMAP table is not enough, Pgcedit creates Prev/NextPGC links to itself in a "PlayAll" title.
WinDVD will disable seek bar if these links are set, so you will have to set these links to zero too.

[r0lZ]

Since I've run into playback problems with certain standalones, the 32K gap function is always turned off.
I don't burn my ISO files automatically, usually burn them later with ImgBurn. This was the case this time too, only wanted to create the image file.
OK, thanks for the directory listing.

If you don't use the 32K gap option, maybe you could try to do a "Get VTS Sectors" with IfoEdit on the IFOs prepared by PgcEdit for the burn, and burn them with ImgTool Classic. The result should be exactly the same than with PgcEdit (for a single layer DVD w/o the 32K gap option.) If you don't have issues, send me those IFOs too. It will be easy to see where is the difference.

Are you sure the playback problems are caused by the 32K gaps? Seems strange. Those gaps are lagal, and I have already encountered many commercial DVDs with gaps. IMO, enabling this option cannot hurt.

[r0lZ]

@odbo2005

Yes, I am currently working to solve the missing time map problem.

For the Prev/Next PGCN link, seems only software players have issues with them. I have tried this feature on approx 10 standalone players, and all of them accept the Prev/Next PGCN pointing to the same PGC without problem. I'm not sure this trick is legal (in a sequential title), though.

[r0lZ]

@erdoke

OK, thanks to your new directory listing, I have verified all VTS pointers. Everything is fine! The burn function of PgcEdit is not the culprit!

However, there is something really strange. VTS 3 exists, but is not referenced in the VMG tables! Also, the PGC in VTS 3 is not associated with a title number, and is therefore missing in VMG_TT_SRPT. IMO, that's illegal, and might be the cause of the problem, though I don't understand why mkisofs complains on VTS_02_0.BUP.
Note that this problem is present in the original IFOs, too.

You should try to remove VTS3 completely. There are 2 jumps from the VMGM domain (in PGCs 4 and 6) to VTSM 3, root menu, but anyway, this root menu PGC doesn't jump directly or indirectly to the title PGC in VTS 3. Therefore, the navigation is broken anyway.

Try the DVD -> Delete last VTS in DVD function (and remove lines 3, 5 and 6 in VMGM PGC 4 and 6 to fix the navigation.) This will probably solve the problem.

I wonder what you did to obtain this strange structure, and if PgcEdit is the culprit. Do you remember exactly what you did to produce the original IFOs (named "IFOsFromPgcEditBackup" in your archive)?

[ocular]

rOlZ

Thanks for advice on parent directory. Have cleaned it out and burnt iso onto DVD+R DL via ImgBurn, PgcEdit handles layer break perfectly with its default settings, better than recordnow.

DVD+r DL + PgcEdit + ImgBurn = success at last on standalone DVD player

[r0lZ]

Thanks for the info, ocular! I'm glad it worked! :)

[erdoke]

My SONY standalone doesn't even start playing DVDs with 32K gap enabled.

VTS_03 should be referenced in VIDEO_TS.IFO because PgcEdit misses phisically deleted VTS_03 files when importing. After deleting last VTS just like you advised, another strange error message appears:
http://erdoke.uw.hu/Pix/PgcEdit_Get_VTS_Sectors_Error.png

If clicking "Yes", same error occurs when creating ISO file. If selecting "No" a couple of more windows of the same kind appear, but in the end there is a "Fatal error" message.

IFOEdit did not show any sector problems.

It is a movie I got to fix, I couldn't create anything like this. :)

[r0lZ]

Well, seems your DVD is really damaged! Strangely, I have tried to remove the last VTS on the IFOs you send me, and I have no problem!

VTS_03 should be referenced in VIDEO_TS.IFO because PgcEdit misses phisically deleted VTS_03 files when importing.I don't understand. What have you imported, and how? PgcEdit should not need the VOB files when loading the DVD (except to find the BOVs, but it's not really needed.)
Anyway, there is a big error in VTS 3, and you have to find a way to get rid of this titleset. Try to start with a new DVD (File -> New DVD), and import the valid VTS titles and menus...
But, IMO, it is easier to restart everything from the beginning.
BTW, is it an ARccOS protected DVD?

My SONY standalone doesn't even start playing DVD-s with 32K gap enabled.I can't believe that! If it's true, it should hang on many commercial DVDs, too, since the gap method is widely used. Are you sure the problem was caused by the 32K gaps? Have you tested it with several DVDs? What is the model number of your Sony player? I have a very old Sony DVP-S725D, and it has no problem with the gaps.

[erdoke]

Thank you for your help r0lZ!

I've removed VTS_03 with DRM Pro and now ISO file creation is OK.
You guess right, it is a copy of an ARccOS protected DVD, but I had to remove 59 cells and many cell commands from the movie PGC. Some poor AnyDVD stuff I guess. :devil:

As far as the 32K gap function is concerned, I had to throw out many discs because they simply did not play at all. Though it was a long time ago, I should check it again with my new player and the old Sony as well.

[r0lZ]

Thanks. Please keep me informed. At my knowledge, you're the first person who reported a problem with the 32K gaps, and I want to be sure the method is accepted by all standalone players. Anyway, the method is legal, so, if your Sony has trouble with the gaps, it's probably a bug in your player.

[jinjin_jp]

I've been understood "the first cell of PGC must be Layer-Br. cell".
But when ripping ARccOS DVD by AnyDVD(ver5.9.6.1/trial), the first cell of PGC is not Layer-Br. cell.
http://img116.imageshack.us/img116/8012/anydlb0605261gy.th.jpg (http://img116.imageshack.us/my.php?image=anydlb0605261gy.jpg)
Isn't it illegal ?
Is it better to correct the cell-type to Layer-Br. cell ?
Or, my understanding is wrong ?
Regards.

[bigotti5]

Yes, first cell of a pgc must be flagged as non-seamless ("Layerbreak")

[blutach]

Somebody gunna tell me how we get 171 titles on erdoke's DVD?

And yes, jinjin_jp, the flag should be 2.

Regards

[jinjin_jp]

@bigotti5, blutach
Thanks for the reply. I understand.
It seems to be AnyDVD's bug.

the flag should be 2.
I think the cell type should be 2(STC discontinuity), too.
But when ripping ARccOS DVD by DVDFabDecrypter(ver2.9.7.7), the first cell type of PGC is "0".
Is it legal or bug ?

Regards

[r0lZ]

Somebody gunna tell me how we get 171 titles on erdoke's DVD?I can!
There are only 2 titles in this DVD, for 3 titlesets!

I'm not sure the fact that the last titleset is not referenced in the VMG_TT_SRPT table, and therefore has no Title number associated with it, is a part of the protection, or if the ripper did something wrong.

Anyway, when you remove the last titleset, the PgcEdit method to verify that the title numbers present in the last titleset are really the highest titles in the DVD is correct, but fails when there are no titles. The number of titles in VMG_TT_SRPT table is therefore decreased by a nagative number, and so it is increased! The table, however, is truncated at the right position. Therefore, the number of entries doesn't match the table length, and the new (bad) entries are just garbage.

I did not notice this problem yesterday, before the message pops up only then the DVD is saved, and in my test, I haven't saved it.
I have fixed this problem. Now, when the user remove a titleset with no title numbers in VMG_TT_SRPT, this table is not modified at all.

[r0lZ]

Is it legal or bug ?
It's illegal!
But maybe in the protected titles, it's something that the protection adds, though I don't think so. It's probably a bug in the ripper.

[erdoke]

@jinjin_jp

Do not bother if it is legal or not, just remove every cell that has been inserted to be able to rip the DVD. Your first cell should be the first movie cell and of course be marked as non-seamless (2). Remove all unnecessary cell commands as well.

[r0lZ]

Look at the screenshot. The sells are removed, and there are no more cell commands. IMO, the ripper removes one cell too much, and doesn't clear the seamless flag as it should.
DVDFab Decrypter is not a very good ripper!

[jinjin_jp]

Comparing the first cell of ARccOS DVD(example is "Bewitched).
http://img154.imageshack.us/img154/7950/compfirstcell0605269it.th.jpg (http://img154.imageshack.us/my.php?image=compfirstcell0605269it.jpg)
(1)AnyDVD : CellType：8(Seamless、 STC continuity)
(2)DVDFAbDecrypter : CellType：0(no-Seamless(LayerBreak)、 STC continuity)
(3)DVDDecrypter and Plugin :CellType：2(no-Seamless(LayerBreak)、 STC discontinuity)

Only (3)"DVDDecrypter and Plugin" seems to be legal.
Why it remains one more cell which others remove as first cell ? Is there any reason ?
(Edit) Is it related to cell type ?

[r0lZ]

It confirms that DVD Decrypter is still the best ripper around!

However, DVDD do not remove the bad cells because it's an old program, and it is not aware of the newest ARccOS protections.
If you remove this cell manually in PgcEdit, it will fix the cell flags for you!

BTW, the bug of the other rippers is probably caused by the fact that they remove the protected cell. They omit to fix the cell type flags of the next cell (that is now the first one in the PGC).

[jinjin_jp]

@r0lZ
Thanks for the reply.
I think also DVDDecrypter with PgcEdit-plugin is best.

But I can't understand one thing.
http://img376.imageshack.us/img376/6038/crap0605261jb.th.jpg (http://img376.imageshack.us/my.php?image=crap0605261jb.jpg)
Inspite that "Remove crap(after rip)" of PgcEdit-plugin recognize cell_22 as "tiny cells[<1sec]"(blue letter), the cell is not recognized as "automatically find cells to remove".
"Tiny cells[<1sec]" isn't to be removed cells ?

[r0lZ]

Well, I'm not sure of the reason, but I know that the plugin deletes only the cells up to but not including the last one with the seamless flag clear.
I guess the reason is that it is possible that the first cell with real video begins with an open GOP. Deleting the previous cell can therefore be dangerous.
The last non-seamless tiny cell is normally used as the target of the last jump made by the cell commands, and therefore, it should be safe to cut the video at this point.
Anyway, leaving a tiny cell of 1/2 sec that is normally played doesn't hurt.

[jinjin_jp]

@r0lZ
Thanks for the reply.

I tested according to your advice, I could find the feature of PgcEdit plugin.

"Remove crap(after rip)" of PgcEdit-plugin recognize cell_22 as "automatically find cells to remove", after correcting cell_23 to LayerBreak cell (celltype=0).
It seems to judge whether remain the last tiny cell or not, depend on that next cell is LayerBreak(non-seamless) cell or not.

(by the way, Cell_23 is not-closed GOP.)

Regards

(Edit)
And as information,
Before, DVDFabDecrypter2.9.5.2 and AnyDVD5.3.2.1 was the same as DVDDecrypter and plugin (remain the last tiny cell).
But now, DVDFabDecrypter2.9.7.9 and AnyDVD5.9.6.1 are always remove the last tiny cell.

[blutach]

Great research jinjin_jp!!!

Remving the last tiny cell can be a pain if you want to fast forward through the credits and no Next PGCN = current PGC is set.

Regards

[jinjin_jp]

Thanks for the info blutach, too.
But I couldn't reply to you because I couldn't what you meaning a little.
Do you mean about tiny cell which is the last of PGC (not ARccOS)?
If so, DVDDecrypter, DVDDFabecrypter and AnyDVD all remain the last tiny cell of PGC.
(I remember DVD2one movie-only mode removes the last tiny cell, and I don't like it.)

[bigotti5]

@r0lz

Are you sure your low mux rate identification is correct?

Here a screenshot from Pgcedit

http://members.aon.at/video.digital/lowmux.png

A check in Vobedit shows - each cell has 146 scr-ticks difference and not 184

[r0lZ]

Well, I can't be sure without seeing the VOBs, but it works fine with my DVDs.
The check works by comparing the scr of the first two nav packs of the cell. If the difference is 146, the mux rate is high, otherwise, it is low. What's wrong?
Have you checked the last VOBU of the previous cell and the first one of the current cell?

[frank]

I hope I'm not too late. There is no need for scanning the bitrate! I have made many DVDs at high bitrate 8000-8500 kbps.
All my players (Two players older than 5 years and one new Philips) play smoothly, no pause at LB.

The implementation of seamless layer break in PgcEdit is very useful.

By the way who introduced the Layer Break Flag? The dvd specs?? No, there are only cell type flags about continuity!
I think it was IfoEdit that indroduced that wrong name.

The layer break discussion results from a stutter/pause problem of standalone players what PC software players don't have. Because I come from the hardware front, a short explanation.

We have three access layers:

1. DVD drive
The drive can access to LBA blocks/sectors, organized in ECC blocks of 16 physical sectors. It's firmware recognizes the media, translates the physical sector numbers into logical ones, and corrects errors. Encapsulated user data (=logical block) is 2048 bytes/sector. Any firmware READ/WRITE access to the media is an ECC block access! If you sequential read from drive the the controller of the drive ensures that you'll get a continous data stream.
To read double/dual layer continously the specs say that the Layer Break address shall be an ECC block (LBA divisable by 16 = ECC block address). Means that the 16 sectors of the ECC are laying on the same layer - LB is starting on L1.

Any application can read logical blocks, it cannot see any layers or other physical structures!! The drive delivers user data continously to the calling operating system.
To read properly the double/dual layer dvd specs say that the Layer Break address shall be an ECC block (LBA divisable by 16). That's a basic demand for double/dual layer recording, regardless of data format (video, audio, data).

The laser focus time is only some milliseconds! If the track buffer doesn't reach you lose one revolution until the block comes again under the laser <100 ms at 1x. To compensate this all special dvd player drives rotate at least with 2x!!

Example:
DVS DSL-710A (One of the oldest well known and most used dvd player drives from Korea)
Speed: 2x (CLV), 1200 rpm to 2800 rpm
Average access time: 250 ms (over the data area)
Data buffer: 512 kbyte

It's data buffer can store up to 256 sectors = 48 msec video, encoded at highest bitrate.
At 2x speed one rotation needs < 50 ms!

As you can see already now: all discussions about lowering bitrate/muxrate are CRAP!

2. File System
OSTA Universal Disk Format (UDF) is the standard DVD file system (v1.02) for DVD-Video disks.
Defines Logical Volume and file access.
That structure is realized by MKISOFS.
Again: This layer does nothing know about dual layer or Layer Breaks! It reads LBA from drive.

3. Play back Control PBC
DVD-Video presents a special data structure hierarchy: Video Manager VIDEO_TS.IFO, Title Sets VTS_xx_xx.IFO, Video Objects VTS_xx_xx.VOB. The access is very primitively via pointers, tables. VOBs have the limit of 1024 kbytes.

And here we meet the cell type flags and this Seamless Playback Joint flag, controlling some behaviour of timers and decoder.
But again: This layer does nothing know about dvd layers! We must tell it by setting the flags.
If the drive is able to deliver the sectors seamless - and the drive does it - then all things should work flawless.

My experience is that there are too much bad dvd media on the market, so that the second layer has 5-10 times higher error rate. After layer break the drive runs into problems.

So far in short.

Greetz
frank

[r0lZ]

By the way who introduced the Layer Break Flag? The dvd specs?? No, there are only cell type flags about continuity!
I think it was IfoEdit that introduced that wrong name.
That's right. The layer break flag doesn't exist! And IfoEdit introduced this wrong name.
But I have added the LB checkbox in PgcEdit's cell table so that the average user can verify or remove it easily. The layer break flag is actually the inverse of the seamless joint flag. It is a fact that the seamless joint flag is usually clear on the layer break cell. When this configuration is found in the middle of the main title, it indicates the position of the layer break, and the seamless joint flag must be set to avoid the pause if you burn a single layer DVD. Since, for most users, the cell type flags are just Chinese, I have decided to leave the LB checkbox, with the IfoEdit name. Note the question mark in the label of the checkbox. It indicates that this flag can indicate the layer break position, but it's not a guarantee!


About your technical explanation:
If your players are happy with a seamless layer break, that's very good. However, I have already read sometimes that it doesn't work with some players. In some case, seems it's useless to set the seamless flag, because the player pauses anyway. In some other cases, the player hangs completely! So, I guess mpucoder is right. It is best to be sure that the mux rate is suitable for this trick!
And anyway, if all players were able to switch layers without the pause, how do you explain that 99% of the commercial DVDs have the seamless joint clear on the LB cell?

[bigotti5]

@r0lz

Here are the values from cell 48


First Nav-pack in Cell 48

[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 199 118 144 222 59 [44 c7 76 90 de 3b ]
SCR 209146395.285
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
......
[0045] Cell elapsed time (BCD) 64 [00000040]
00:00:00.00 / 25 fps
[0049] International Standard Recording Code
............
............
[041b] VOBU third reference frame end block 142 [0000008e]
[041f] VOB ID 1 [0001]
[0421] Reserved 0 [00]
[0422] Cell ID 48 [30]
[0423] Cell elapsed time (BCD) 64 [00000040]
00:00:00.00 / 25 fps
............

First pack following Nav-pack (Video-Pack)

[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 199 118 149 116 141 [44 c7 76 95 74 8d ]
SCR 209146542.070
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
[000d] Pack stuffing length: 0 248 [f8]

[Video Stream]
[000e] Video Stream start code 480 [000001e0]
[0012] Length 2028 [07ec]
................




Same in cell 49, 50, 51, 52, 53. 54, 55
so why is 48, 49, 52 and 55 shown as low mux rate?

Cant find any distinctions to other DVDs except the multiplex delay
which is normally between 20000 and 30000 ticks shows 4478

And anyway, if all players were able to switch layers without the pause, how do you explain that 99% of the commercial DVDs have the seamless joint clear on the LB cell?

the DVD Specification requires that the layer break begin at the start of a non-seamlessly linked Cell and so most replicators would reject compilations with a seamless cell at layerbreak point

just to increase the confusion about seamless flag on layer break cell I have a Superbit DVD that has the layerbreak cell flagged as seamless and the mux rate is high........

[r0lZ]

OK, it's a bug! The remaider part of the SCR value is ignored in my computations, and therefore 209146542 - 209146395 gives 147, not 146. If the floating point values are used, the result is 146.785, which is sitll close to 147.
I will change the test.
Thanks for the bug report!

[laserfan]

...all discussions about lowering bitrate/muxrate are CRAP!
That's right. The layer break flag doesn't exist! And IfoEdit introduced this wrong name....The layer break flag is actually the inverse of the seamless joint flag...
While I don't appreciate some of frank's sentiment/choice of words, I am very glad for his post, because it makes (for me) something crystal-clear which never was before, that the LB flag checkbox really means "this is NOT a seamless joint"! So I think r0lZ that continuing the error of naming as IfoEdit was a mistake. I think it should instead be named "Non-Seamless Joint" or whatever the spec truly says it is.

:stupid:

p.s. r0lZ lest my post sound too harsh, I understand and appreciate/admire that your "floating tooltip" over the Layer Break? column header makes everything perfectly clear. Maybe I should let you whip me with a wet noodle for being so hyperactive as to never have paused & reflected over this point in the past!

:o

[r0lZ]

Well, of course, you're right. I should not use the "layer break" name. But, as I said, I kept this name for the average user. If I rename the flag "non-seamless joint", Mr. Average Joe will not understand that it can represent the layer break point.

It's always the same problem. I can't use only the official terminology, or PgcEdit will be even more intimidating!

[laserfan]

Well, I'm "Mr. Average Joe" just trying to absorb/understand all this stuff myself! But I agree with your decision.

Beside being hyperactive, I am also "anal" and there's no way you could make "non-seamless joint" look good as a column header! :D

[r0lZ]

Right! :D It's also something I must take into account!

[mpucoder]

And you don't want it to look like Scenarist, which would simply be NSM :scared:

[frank]

Originally posted by rOlZ:
And anyway, if all players were able to switch layers without the pause, how do you explain that 99% of the commercial DVDs have the seamless joint clear on the LB cell?...
It is a fact that the seamless joint flag is usually clear on the layer break cell.Yes, but then in every case is a change of VOB-ID -> non-seamless. Internal counter and decoder/buffer resets follow in the dvd-controller logic. Slow 8-bit controllers. That needs time.

The specs are about 10 years old. At this time they didn't know enough about electronics. They stated a VOB-ID change, set STC and cleared seamless playback cell flag. That works, but some players stop because of slow reset operations.

Test this:
If you set STC and clear the seamless joint flag on a cell of a single layer dvd then most players will stutter. I think the STC is the critical part. Now we know: they have a slow mpeg/dvd controller.
But has nothing to do with the drive. It can't see cell flags.

Originally posted by rOlZ:
In some case, seems it's useless to set the seamless flag, because the player pauses anyway.Same case as above - slow controller.
...In some other cases, the player hangs completely!They set the seamless flag and there was a VOB-ID change (STC flag set) ->non-seamless Layer Break.

If your players are happy with a seamless layer break...I have a lot friends - same procedure... they are happy with seamless Layer Break :D

Originally posted by bigotti5:
I have a Superbit DVD that has the layerbreak cell flagged as seamless and the mux rate is high........No wonder :D
Seamless Layer Break (no VOB-ID change) or new player.

Summary:
The drive reads all ECC-blocks without a break. It reads linear numbered blocks from start to end of a double layer dvd. Because of that the dvd-controller needs no information about Layer Breaks.
The dvd-controller, especially the mpeg decoder (buffer management) needs information about time wasting operations: VOB ID change, synch ops, timer resets, jumps... This is done by flags.

My rules to LB point:
1. If VOB-ID changes then CLEAR the seamless joint flag. (Set LB in PgcEdit)
Or remux title into only one VOB-ID - then see case 2.
2. If VOB-ID not changes - seamless Layer Break - then SET the seamless joint flag. (Clear LB flag in PgcEdit) Cells are continous linked, STC cleared.

[r0lZ]

Yes, but then in every case is a change of VOB-ID -> non-seamless.
Not always! There are many DVDs with the layer break inside a VOB (where only the cell ID changes.) The seamless flag is set, too.

Anyway, I don't say you're wrong. IMO, it is necessary to test the method to be sure it works with a specific player. And it is best to have as much info as possible on the cells, and that's exactly what I've tried to do in PgcEdit. We can discuss the necessity to display the pink warning in some circumstances, but that's not essential.

[ux-3]

small observation: when choosing burn speed in the pgcedit menu, I am offered 2.4x AND 2,4x. I wonder if this is a feature or a glitch?

greetings
ux-3

[r0lZ]

Well, it's because ImgBurn needs 2,4 instead of 2.4 on european systems (where a floating point number is really a floating coma number.) Since I don't know how to test the locale settings, I kept both numbers.
If somebody can tell me how to know the numbers format, I'll change that.

[r0lZ]

PgcEdit v 7.1

A. Burn DVD: New "Seamless Layer Break" option in the Layer Break selection dialogue, allowing to set the seamless flag of the LB cell. Theoreticaly, the Seamless flag must be clear, but it appear that it is possible to set it in most circumstances. However, this method can be incompatible with some old players, but is used on some commercial DVDs (among others, Sony Superbit DVDs.) A pink warning is displayed in the risky cases. Technical info: http://forum.doom9.org/showthread.php?p=819669#post819669
A. Burn DVD: New option (under Linux and MacOSX only) in the layer break dialogue to modify the IFO files only, without creating the ISO image. This option can be used to burn the DVD files directly with growisofs.
A. New function to recompute the VTS_TMAPTI table (Time Map) of the current Title PGC, or all time maps of the current title domain or of the DVD. This function is called automatically when a time map needs to be modified but can also be called on demand via the "DVD" and "Title" menus to fix bad time maps, or to build the time maps of non-sequential titles.
E. Kill Playback: The first cell command that is normally executed is now included in the pre-commands to minimize the risk of navigation errors (but only if this command is useful and legal in the pre-commands.)
E. PGC Editor's cell list: When a cell command is defined and the seamless joint flag of the next cell is set, the "Layer Break?" checkbox is now highlighted in pink, to warn the user that the cell command is executed only when this seamless flag is clear (ie, layer break checkbox ticked.)
E. When a titleset is present on disc but not referenced at all in the IFOs, it is now possible to move it automatically to a special backup folder. Previously, the user has to do it manually.
E. Improved the VOB desynchronized error check to identify the tiny black cell added by PgcEdit at the end of the VOB files but not referenced in the IFOs. (This situation can happen when the IFOs are not saved by the user after the creation of a new cell.) It is now possible to reuse this cell with the PGC Editor functions "Create new cell" and "Reassign VOB/ Cell ID" with the option to create a new blank VOB cell. Previously, a VOB Desynchronized error message was issued.
E. Burn DVD: The Shutdown Computer option is not remembered any more from session to session. That was too dangreous.
F. After an Import VTST Title, Import FP Clip or Import Title intro/closing clip, the number of BOVs were not initialized correctly, which caused some other functions (notably Clone PGC) to crash.
F. Clone PGC function did not update the TTN internal variables correctly.
F. Trace: A warning is now issued if a cell command exists, but the cell that follow the current cell has its Seamless flag set. The cell command cannot be executed in this case.
F. Blank Out all Title PGCs: The cells table was wrong when this function was applied to a Title domain without VOB files present on HDD.
F. Replace VTST Titles: The streams attributes of the current menu domain were copied from the imported IFO. Now, the table is left untouched.
F. Remove cell in PGC Editor: When removing the last Program, the PG number was kept in the table, and forced to 0. Now, it is correctly removed.
F. Info -> Jumps from VMG to Current VTS: Some menu buttons or BOV commands were wrongly included in the output.
F. Fixed a bug occurring in very rare circumstances: The number of BOVs of the PGC was sometimes wrong after a delete cell from the PGC Editor.
F. Tools configuration didn't work if FixVTS was not used before calling it.
F. When a titleset was removed or imported, the parental management table VMG_PTL_MAIT was not updated.
F. Some minor GUI bugs fixed.
F. The Download Daemon Tools link was dead. Changed to current one.
W. Workaround for a little discrepancy in the faster mkisofs.exe program provided with PgcEdit. This exe doesn't set the error level like the original one, and therefore PgcEdit was unable to discover if it has failed.


DVDShrink plugin v 2.0

A. New function to redo completely from scratch the authoring of a DVD created by DVDShring in reauthor mode.


LU (Language Unit) plugin v 1.1

A. New function to clone the current LU, with a new language code. Useful to translate a still menu to another language.


Enjoy!

[Rippraff]

Thanks a lot r0lZ for the new version(s). :)

Cu Rippraff

[Grave]

amazing, just tested on one dvd with missing time map and after pgcedit did its black magic it finally works as expected.
great job, many thanks :)
in upcoming days i'll be going through other dvds with missing/empty tmaps i encountered.
btw is there a way to check actual timemap info (eg pgc editor?) or see summary information (info menu?), its no big deal though i can check it with ifoedit :)

[ux-3]

I just downloaded the new version. Thanks a lot. I have both 7 and 7.1 on my desktop. I was about to process a DVD with 7.1, when something odd occured. I went back to 7.0 and that worked as expected. A look at the changes suggests this: E. Kill Playback: The first cell command that is normally executed is now included in the pre-commands to minimize the risk of navigation errors (but only if this command is useful and legal in the pre-commands.)


Here is what happens in 7.1: I trace to a thirty seconds clip (no buttons). When I hit "kill playback", I see no change in the instruction window.
before and after:
********** pre commands:
********** post commands:
[30 06 00 01 01 83 00 00] 1 (JumpSS) Jump to VTSM 1, Root menu (TTN 1)
********** cell commands:

When I hit "Next PB" the adjacent button "Run" changes to "Break" and turns red. I won't get any further this way.

In 7.0 I am told "you killed a menu PGC playback".
A softplayer will play the disk, I shall burn some part to see if a hard player gets to the menu too.

[r0lZ]

@Grave:

No, to be able to display really meaningful info on the time maps, I have to read all nav packs of the VOBs, and that's very long.
But I can add a function to display a summary of all PGCs of all VTS, with the time unit and number of entries in the map, if you wish. It's not sufficient to be sure the time map is correct, though.