PGCedit Seamless layer break discussion..

[jamos]

I am a bit confused. looking at the dual layer images created from PGCedit 7.0 it seems the discontinuty flag is not set. Is this normal as I see other programs such as nero sets it?
Image of a iso from PGCedit
http://img242.imageshack.us/img242/449/duallayer8uo.png (http://imageshack.us)

note: I can manually set the discontnuity flag, but that kind of defeats the purpose of letting PGCedit choose the layer break doesn't it or does it really not matter?

[blutach]

The STC discont does not need to be set unless there is an actual discon in the system time clock. You would typically see this happen when a VOB ID changes (cell 36 should have been a 10), and in other cases.

For the LB, it is important that the cell is marked as seamless. I would suspect that the orig LB was on 36 but you manually moved it to 34. It is correctly set up to break at cell 34.

As for Ner0, I wouldn't trust it at all.

Regards

[jamos]

The STC discont does not need to be set unless there is an actual discon in the system time clock. You would typically see this happen when a VOB ID changes (cell 36 should have been a 10), and in other cases.

For the LB, it is important that the cell is marked as seamless. I would suspect that the orig LB was on 36 but you manually moved it to 34. It is correctly set up to break at cell 34.

As for Ner0, I wouldn't trust it at all.

Regards
Thanks, that makes much sense!

No the reason 36 is not a chapter cell is because this is a merged DVD I get this because of the extra vobs it adds when I merge them (ie start of a new vob has to be a new cell) I did not know that it should be a 10 though I manually changed it back to 8 guess I should of left it a 10 (although it plays fine so maybe I am ok).

[r0lZ]

I suppose that, theoretically, it is better to have a STC discontinuity in the VOB files at the LB. But if you select a cell that has not the STCD flag set, I don't think it's a good idea to force it, since it will not reflect the reality. Anyway, I haven't read reports on playback problems when the STCD flag is not set. Maybe the pause is a little bit longer to let the player resynchronize the audio and the video?

[jamos]

I suppose that, theoretically, it is better to have a STC discontinuity in the VOB files at the LB. But if you select a cell that has not the STCD flag set, I don't think it's a good idea to force it, since it will not reflect the reality. Anyway, I haven't read reports on playback problems when the STCD flag is not set. Maybe the pause is a little bit longer to let the player resynchronize the audio and the video?
In all the pressed dvds that I have looked at the flag is not set at the layer break, it looks like the above screen shot. As far as the pause I have not noticed any difference either way. I would say unless the break is at the starting cell of a new VOB that it should not be set.

[r0lZ]

Thanks. That confirms what I've seen, and that PgcEdit is not faulty.

[jamos]

Thanks. That confirms what I've seen, and that PgcEdit is not faulty.
Don't you love when I answer my own questions..:p

[r0lZ]

Yeah! :goodpost: :p

[jamos]

Also looking at the Phantom Menace DVD they have a layer break on a new VOB cell. Discontinuity is set at the layer break. I would assume that is the best way to do a layer break as Frank stated. But, for a break that is NOT the first cell of a VOB, discontinuity should be set off.

[r0lZ]

Yes, it's a good method, also recommended by mpucoder.

Though it is true that a cell at the beginning of a new VOB must have the STC flag set, I'm not sure a cell that is not at the beginning of a new VOB cannot have the STC discontinuity (and its flag.)

[mpucoder]

Just look at the SCR values, if they do not reset (or change by a large amount in either direction) then the flag should not be set - and is unaffected by the layer break. In general cells within a vob are continuous and seamless, a new vob should reset the clock (and may be seamless or not).
I've been researching the "seamless layer break" and seen recomendations to make the layer break either between cells of the same vob or between seamlessly joined vobs to yield a smooth playback. Jim Taylor, in DVD Demystified, says "A cell cannot be spread across both layers of a disk. This rule is also supposed to apply to a pair of cells intended to play seamlessly, but so-called seamless layer changes can be made by violating this rule." (2nd ed, p 264)
I believe he is trying to say that the rule is "a pair of cells intended to be played backed seamlessly should not be spread (or split?) across both layers" and that by violating this rule, ie making the layer break between 2 cells intended to be played back seamlessly, a seamless layer break will result.

[r0lZ]

Great info, mpucoder!

So, it should be possible to leave the seamless flag set on the LB cell! Do you think this rule violation is compatible with all players, or is it a risk of crash/freeze, especially with old standalone players? I thought the player need some time to switch from a layer to the other one...
I might add an option to leave the seamless flag on the LB in the burn setup dialog of PgcEdit. Is it safe?

[bigotti5]

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

[r0lZ]

Thanks, bigotti5. So, it appear that this seamless LB technique requires a special muxing. Difficult for PgcEdit to analyse the VOB file to be sure the seamless flag can be set. Pity! :(

[jamos]

Well so far out of 15 pressed dvds I have never seen the seamless flag set (several had a discontinuity flag set because its break was at the start of the first cell of a VOB). So I am guessing that even if there is a standard to set seamless and multiplex it, it is rarely done. Maybe with older dvds setting seamless was done more often as the older dvd players took more time on layer breaks?

pressed dvd with discontinuity at start of new VOB:
http://img81.imageshack.us/img81/1783/pressed1cg.png (http://imageshack.us)
pressed dvd with discontinuity not set (not at new VOB):
http://img270.imageshack.us/img270/7001/disnotset5mu.png (http://imageshack.us)

[bigotti5]

take a look at Superbit DVD (http://www.sonypictures.com/cthe/superbit/)

[r0lZ]

Thanks, Jamos.
BTW, your second screenshot is a good example of several cells that are not used for chapter points. In this case, it is difficult for PgcEdit to guess which cell was used for the LB (unless the seamless flag is left unchanged during the rip.)

@bigotti5
I haven't analysed a superbit DVD yet.
Do you think superbit really offers a better quality than a good traditional DL DVD? Unless the movie is really long or full of action scenes, I think a perfect quality can be archived without having to use the full DVD size for the main movie. Anyway, the bitrate is limited by the standard. Is it true that the main movie occupies (almost) the full space of the DL DVD?
Honestly, I suspect a commercial trick instead of a real improvement.

[bigotti5]

Perfect quality imo is always subjectively.
I have only one Superbit DVD ("Das Boot") in my Collection and I have not compared with other releases of this movie.

It is the seamless layer change that initiates me drawing attention to Superbit, not the quality (quality is good though).

[blutach]

I don't think I will ever use the seamless layer change - it's just too risky ATM. Many studios are getting smarter about where they put the LB so it is aesthetically pleasing (a scene which fades to black for example, or one where there is no audio or movement for a couple of seconds).

I do like superbit - I have one or 2 (Hannibal I think is one) and it is very good - avergae BR is very high around 7-8Mbps (which doesn't give much room for low BRs - it is almost like CBR encoding). And, r0lZ, the movie occupies ALL the DVD, there are no extras just wasting space.

In any event, as we know, it is a "psychvisual" experience r0lZ, as "perfect quality" is in the eye (literally) of the beholder.

Regards

[r0lZ]

And, r0lZ, the movie occupies ALL the DVD, there are no extras just wasting space.
I know there are no extras. But that doesn't mean that the main movie occupies the whole DVD. Have you verified that the VOB files of the main movie are really around 7GB?

[bigotti5]

I don't think I will ever use the seamless layer change - it's just too risky ..

As mpucoder stated, seamless layer change requires especially muxing, imo no available authoring soft is capable of doing this

[mpucoder]

I gotta find my notes, apparently back in November I knew of an example. There are two issues - seamless and bitrate. Two cells of the same vob will be seamless. You can also join two vobs seamlessly in many authoring programs, including MuxMan 0.17
And being seamless should work in the majority of players. At worst it will still pause while the laser refocuses due to buffer depletion. It won't crash or stop, being seamless makes it easier to play, not harder.
Lowering the mux bitrate helps the buffer depletion problem. Notice this is the mux bitrate, not the combined bitrate, a slightly different aspect of program streams. The normal mux rate is 10.08 and the lower rate for interleaving is 8.0 It may seem as though it wouldn't matter if the combined rate is low there will be less data to handle and the buffers can fill up before the layer change. But the lower mux rate signals to the player that something is going to happen that requires cramming the buffers full (usually angle or story skipping)
Even so, a combined bitrate of 8.0 or less should also work in modern players which have buffers many times larger than the target decoder model.

[jamos]

I gotta find my notes, apparently back in November I knew of an example. There are two issues - seamless and bitrate. Two cells of the same vob will be seamless. You can also join two vobs seamlessly in many authoring programs, including MuxMan 0.17
And being seamless should work in the majority of players. At worst it will still pause while the laser refocuses due to buffer depletion. It won't crash or stop, being seamless makes it easier to play, not harder.
Lowering the mux bitrate helps the buffer depletion problem. Notice this is the mux bitrate, not the combined bitrate, a slightly different aspect of program streams. The normal mux rate is 10.08 and the lower rate for interleaving is 8.0 It may seem as though it wouldn't matter if the combined rate is low there will be less data to handle and the buffers can fill up before the layer change. But the lower mux rate signals to the player that something is going to happen that requires cramming the buffers full (usually angle or story skipping)
Even so, a combined bitrate of 8.0 or less should also work in modern players which have buffers many times larger than the target decoder model.
So are you saying if I split a cell in a vob, added the layer break to the new cell and was Able to set the flag to seemless (which you cannot do now with pgcedit on layer breaks) without remuxing it would work better (ie buffer would be full still) on the break or not?

[r0lZ]

... and was Able to set the flag to seemless (which you cannot do now with pgcedit on layer breaks) ...
If you want to test it, you can set the seamless flag this way: start PgcEdit's burn function, but abort the ISO creation. Change the seamless flag and save. Create the ISO with ImgTool Classic or launch the MakeISO.bat file created by PgcEdit in your %TEMP% directory. However, I'm not sure ImgBurn will let you burn the image without resetting the seamless flag. Also, if you want, I can do a version which doesn't clear the seamless flag on demand.

[mpucoder]

That would be really great if you could burn with the seamless flag set, it would answer some questions. And while you are working on that, I am working on another mux directive for MuxMan that will allow changing the mux rate. With both changes we should be able to duplicate what superbit and others are doing.

[jamos]

If you want to test it, you can set the seamless flag this way: start PgcEdit's burn function, but abort the ISO creation. Change the seamless flag and save. Create the ISO with ImgTool Classic or launch the MakeISO.bat file created by PgcEdit in your %TEMP% directory. However, I'm not sure ImgBurn will let you burn the image without resetting the seamless flag. Also, if you want, I can do a version which doesn't clear the seamless flag on demand.
I can try this.

Edit: ok I created the iso with no layer break the old layer break set to seemless..

Now I get this when trying to burn with IMGburn
http://img139.imageshack.us/img139/3743/imgburn7px.jpg (http://imageshack.us)

Maybe a modified version of PGCedit that allows both the layer break set and the seemless flag set could be done and sent to me? Then I could try imgburn again.

[mpucoder]

Start with a cell or vob that already is seamless. Setting the flag when the mux is not seamless only results in a hang on my Sony players.

[bigotti5]

I am working on another mux directive for MuxMan that will allow changing the mux rate. With both changes we should be able to duplicate what superbit and others are doing.

Great - muxman is overtaking scenarist, seamless multistory, seamless layer change, multiangles, seamless b*****...... ;)

[r0lZ]

Jamos, you're right. You have to change the seamless flag with IfoEdit (w/o Get VTS Sectors!) If you save the modified DVD with PgcEdit, it will recompute the VTS sector pointers as for a single layer DVD.

Anyway, I'll do the modification in PgcEdit...

[jamos]

Start with a cell or vob that already is seamless. Setting the flag when the mux is not seamless only results in a hang on my Sony players.
I did pick a seemless cell I think the problem is that pgcedit clears the layer break when I do this.

[jamos]

Jamos, you're right. You have to change the seamless flag with IfoEdit (w/o Get VTS Sectors!)
what cell value would I change this to other than 8?

I really think if the flag is anything but 2 or 0 that IMGburn will not work.

[r0lZ]

Forget it, and download PgcEdit_winexe_7.0.1_beta1.zip (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_7.0.1_beta1.zip). Change the Seamless LB state in Options -> Input/Output, and create the ISO normally.

However, I'm pretty sure ImgBurn will clear the seamless flag before burning the image. Maybe you have to use the good old DVD Decrypter? PgcEdit should still support DVDD. Just configure it in the burn setup dialog. Or launch it manually, and configure the LB LBA in its setup dialog.

I haven't a DL DVD to test, so, let me know if ImgBurn or DVDD works.

[r0lZ]

Just fixed a last minute little bug! If you have already downloaded the beta, please download it again!

[jamos]

OK burning with decrypter now manually set the layer break to what pgcedit said it was at. When I look at the image with pgcedit (mounted with dameon tools) it shows no layer break.

[jamos]

Looks like a sucess layer break still marked 8 on finished disk. Though maybe you could show the layer break cell when i reopen it with pgcedit as a 8 with the layer break marked?

[jamos]

Playback on my Sony Home player is now Flawless at the layer break no pauses or skips with the new disk.:D

Now the question is: does burning with decrypter and setting the layer break manually do a better job than imgburn and is what is causing the no pause? So I guess I would need to test decrypter with the layer break set to non seamless as in the old PGCedit version to truly test if it is the seamless that is doing this or just decrypter burns layer breaks better than the latest version of imgburn.

p.s. just bought 10 more dual layer disks at newegg :p


mkisofs log for DVD
From:
DVD-TEXT General Name: ""
Provider ID: "IFOEDIT BY DERROW"
Number of VTS: 1
Output file:
Volume label:
Running under windows (OS type: Windows NT)

mkisofs 2.01-bootcd.ru (i686-pc-mingw32)
Layer break is at absolute sector 2077232. (Offset in L0 is 68576.)
Layer break cell:
2008656: VTST 1 , 1 TTN 1 (4:26:24) Title 1 Cell 41 (00:08:55.08), V/CID: 5/37
EXPERIMENTAL: The seamless flag is set on the LB cell!

The pad was 68592 for file VIDEO_TS.IFO
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 4248
Path table size(bytes): 42
4154455 extents written (8114 MB)

ISO created OK.

[blutach]

Very interesting thread. Might be a bit hit and miss with some players though.

Regards

[jamos]

It is not Decrypter, i reburned the same dvd with its layer break set to 0. Small pause at layer break. So it does look like setting the layer break seemless works (at least with my sony homeplayers). Now we just need imgburn to support this type of break:p

[jamos]

Very interesting thread. Might be a bit hit and miss with some players though.

Regards
try it and see if it works for you, if you have any dual layers blu. Maybe older players will have issues (but they have issues with burned dual layers anyways).

[dirio49]

However, I'm pretty sure ImgBurn will clear the seamless flag before burning the image. Maybe you have to use the good old DVD Decrypter? PgcEdit should still support DVDD. Just configure it in the burn setup dialog. Or launch it manually, and configure the LB LBA in its setup dialog.

I haven't a DL DVD to test, so, let me know if ImgBurn or DVDD works.

Can't you do the same thing with imgburn?

Settings-->Write-->Layer Break--->Change from calculate optimal to User specified.
shouldn't that work the same as DVDD.;)

P.S.
Do you people think that LUK would be interested in this discussion?

Peace out.

[jamos]

Can't you do the same thing with imgburn?

Settings-->Write-->Layer Break--->Change from calculate optimal to User specified.
shouldn't that work the same as DVDD.;)

P.S.
Do you people think that LUK would be interested in this discussion?

Peace out.
I do not think it is the manually setting the layer break that is the issue (which you have to do with decrypter to keep it at the correct position), it is that imgburn will report a error or force the layer break into a 2 or 0 (non-seamless breaks) is what we are worried about. But, yes LUKs input on what imgburn will do to the layer break would be appreciated as I do not want to use another disk to test his program with this without confirmation.

[jamos]

2nd title flawless, no skip at layer break using seamless break;) and decrypter to burn.

[jamos]

Third title tested no pauses at layer break :)

[jamos]

4th DVD tested no pause at layer break..looks like it works well.

[r0lZ]

Thanks for your tests, jamos.

Could you specify if the LB in your tests was set at the original LB location, or at the start of a VOB (where the VOB ID changes)?

[r0lZ]

Looks like a sucess layer break still marked 8 on finished disk. Though maybe you could show the layer break cell when i reopen it with pgcedit as a 8 with the layer break marked?I don't understand your question very well. No, the flags are always displayed as they are on disc. The layer break checkbox is just a shortcut to the seamless flag, for the newbies. (Its value is actually the inverse of the seamless flag.)

[jamos]

I don't understand your question very well. No, the flags are always displayed as they are on disc. The layer break checkbox is just a shortcut to the seamless flag, for the newbies. (Its value is actually the inverse of the seamless flag.)
My question is there is no way to look at the burned disk and tell where the layer break is at using seamless breaks with PGCedit? here is what i see from a seamless burn that I have done. Break is at chapter 30. Is there a another tool that would show this or is there no way to display this sense it is seamless?

Seamless burn:

http://img90.imageshack.us/img90/7184/duallayer8ou.png (http://imageshack.us)

P.S. I put a post in LUks forum on if there is a way to call imgburn and set the layer break position manually through a command line option, and if it will leave the layer break seamless.

[jamos]

Thanks for your tests, jamos.

Could you specify if the LB in your tests was set at the original LB location, or at the start of a VOB (where the VOB ID changes)?
Break is in the middle of the VOB on 3 cases (as in screenshot above), at the start of a VOB in one case, all no pause. All of my layer break positions are not the original positions of the layer break as these are merged DVDs. But, like I said up above using the same image and using the non-seamless flag I did get a pause, so it is the seamless flag that is making my DVD player not pause and Nothing Else (IE burn or burner as I tried several different burners (my Plextor, my Liteon and my Pioneer) and they all worked perfectly with seamless).

[r0lZ]

In fact, by looking at the IFOs, it is impossible to know for sure where the layer break was, even if there is a cell with the seamless flag clear. The non-seamless cell can be there for different purposes (though, generally, in a feature movie, it's the layer break.)
You can try to guess where it was, by looking at the VOB ID change, or by searching an unique cell that is not used as a chapter point. The presence of the STC discontinuity flag is also a good indication.
If you burn with the seamless flag set, it is even more difficult to loacte the original LB cell, since this indication is lost.

[r0lZ]

All of my layer break positions are not the original positions of the layer break as these are merged DVDs.OK. Then, I reformulate my question: did you use the merge point for the layer break?

But, like I said up above using the same image and using the non-seamless flag I did get a pause, so it is the seamless flag that is making my DVD player not pause and Nothing Else (IE burn or burner as I tried several different burners (my Plextor, my Liteon and my Pioneer) and they all worked perfectly with seamless).I understand that. I just wan to know if something special exists in the muxing of those LB cells (as explained by mpucoder), or if the trick works with all cells. In the latter case, that would be really great!
I need this info to know if I can safely add the "Seamless layer break" option in PgcEdit, or if I still have to display a warning, or even to suppress it.

I have also PMed LUK! I hope he will reply in this thread soon...

[r0lZ]

For those of you who are interested in this discussion, LUK! has replied in the ImgBurn support forum, in this thread (http://forum.imgburn.com/index.php?showtopic=1337), started by jamos.
Seems ImgBurn is already capable to burn the ISO w/o changing the seamless flag.

[jamos]

OK. Then, I reformulate my question: did you use the merge point for the layer break?
In one case yes (where the start of the vob was it was the merge point). In the 3 other cases no, they were not the merge points. They were existing chapter point cells withen the VOB or a split cell that i added with vobblanker withen a VOB.

I understand that. I just wan to know if something special exists in the muxing of those LB cells (as explained by mpucoder), or if the trick works with all cells. In the latter case, that would be really great!
I need this info to know if I can safely add the "Seamless layer break" option in PgcEdit, or if I still have to display a warning, or even to suppress it.
Nothing special in muxing. This is strictly PGCedit that is causing it not to pause. One of my tests was taking PGCedit and setting the layer break as normal(ie non-seamless) and burning that with decrypter, I got the pause. The next test was taking the SAME post edited directory and just turning on your seamless break option then burning it again with Decrypter. No pause.



I have also PMed LUK! I hope he will reply in this thread soon...
Cool, he replyed to my post in his forum apparently if we manually set the layer break, as in decryptor, and use imgburn to burn it, it will leave the layer break seamless. I asked if there was a way we could call his program and set the layer break positon in a runtime parameter. So if we called his program from PGCedit it would send in the break position as it does with Decrypter. Maybe we can already do this??

Edit: I see from the other discussion is that yes we can if we launch Imgburn from PGCedit. I have not tested Imgburn with seemless yet.

[r0lZ]

Yes. LUK has replied in his forum too.

All versions of ImgBurn are callable with a CLI argument to pass the layer break. It's what PgcEdit does (but not when DVD Decrypter is used.) When the /LAYERBREAK argument is present, ImgBurn does not verify the IFOs, and burn directly. Therefore, you can safely use ImgBurn to burn with or without the seamless flag. As long as it is properly set in the IFOs by PgcEdit, it should be respected by ImgBurn.

As a consequence, I have already moved the "Seamless layer break" option from the Options menu to the main burn GUI.

Another interesting note by LUK!: Seems that most players are able to cope with the layer break position at any place, including in the middle of a cell! But the split point must be at a NAV Pack. A new version of ImgBurn will probably support this method as well, but I don't think I will implement it in PgcEdit, because it's too risky. Anyway, it is easy to find a nav pack at the right position, without having to offset the VOB files to align it with an ECC bloc.

[jamos]

Great news! I look forward to your new version. As for using nav pack breaks in the middle of a cell, I agree newer players may not have issues with it but older players may have issues. Best to leave PGCedit as DVD complient as possible. I can always split a cell if i need to with vobblaker to get a layer break cell and with seamless it shouldnt even matter on my dvd players where it is as they will not pause.:D

[r0lZ]

PgcEdit_winexe_7.0.1_beta2.zip (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_7.0.1_beta2.zip)

Note that I have changed my mind again. The option is now in the LB cell selection dialogue. IMO, it's the best place.
I have also removed the warning, but the text beside the checkbox is explicit enough.

[jamos]

PgcEdit_winexe_7.0.1_beta2.zip (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_7.0.1_beta2.zip)

Note that I have changed my mind again. The option is now in the LB cell selection dialogue. IMO, it's the best place.
I have also removed the warning, but the text beside the checkbox is explicit enough.
Will it stay checked or will I have to check it every time I burn?:thanks:

[r0lZ]

It stays as you leave it! :)

[laserfan]

As much as I would like to understand the implications of the discussion in this thread, particularly because I have Sony players and sometimes I've seen freezes at the layer break (and I couldn't figure-out from using PgcEdit & IfoEdit what the heck the problem was) I must admit that all this remains "over my head".

I do hope someone here summarizes findings & conclusions for us slow types! TIA!

:confused:

[jamos]

As much as I would like to understand the implications of the discussion in this thread, particularly because I have Sony players and sometimes I've seen freezes at the layer break (and I couldn't figure-out from using PgcEdit & IfoEdit what the heck the problem was) I must admit that all this remains "over my head".

I do hope someone here summarizes findings & conclusions for us slow types! TIA!

:confused:
There will be a new option when you burn a dvd if you use the above beta PGCedit to Burn a dvd. It will say seamless layer break as shown below:
http://img49.imageshack.us/img49/463/imgburn1ih.jpg (http://imageshack.us)
If you check it then you must burn it with imgburn from the burn DVD dialog box to get seemless breaks at the correct position.
http://img186.imageshack.us/img186/9467/burnoptions5cv.png (http://imageshack.us)
This only pertains to Dual Layer.

[jamos]

Ok it is a go with IMGburn. Took the DVD directory I burned yesterday, intentionally split a cell with vob blanker right in the middle of a action scene on a frame with dialog. Loaded it with PGCedit and burned it with Seamless layer break on at that cell using imgBurn. Playback on my sony player is flawless at the layer break no break in action or dialog.:cool:

[r0lZ]

Great! So, it's definitively a good idea to leave the new option in PgcEdit, though I still think that this option should be used with caution. I'm pretty sure it will not work on some players.

[r0lZ]

As much as I would like to understand the implications of the discussion in this thread, particularly because I have Sony players and sometimes I've seen freezes at the layer break (and I couldn't figure-out from using PgcEdit & IfoEdit what the heck the problem was) I must admit that all this remains "over my head".

I do hope someone here summarizes findings & conclusions for us slow types! TIA!

:confused:
If your problem is a total freeze when the player switch to L1, then it's probably caused by a bad disc, a bad burner, a player that doesn't like your media, or its laser is "tired". In any case, it's hardware related. The trick discussed here will probably not help you.

But if you experience only a little pause (approx 1 or 2 seconds), then it's absolutely normal, and the new option in PgcEdit can probably be used to remove it. However, you have to understand that this trick breaks the rules of the DVD-Video standard. With some players, especially old or picky players (like yours?), using this option could lead to even more problems. You have to try it to be sure.

Technical info: The "Seamless Joint" flag is used to specify that a cell must be played seamlessly with the last one. This means that you will not have a pause between the cells. The DVD-Video standard imposes that the cell used for the layer break position has this flag clear, and therefore cannot be played without the little pause. Normally, all cells of a PGC are seamless, except the first one, and the cell used for the layer break, but in some cases, it is also possible to find other cells with the seamless flag clear.
With many recent players, it is possible to leave the seamless flag set on the layer break, and therefore to play it seamlessly. Seems to work fine. Hence the new option in PgcEdit.
With some slow players with small buffers, you will still see a little pause (possibly shorter) but the player will continue normally.
However, if the player needs the seamless flag clear to properly handle the layer break, it can hang completely.
We will see, in the future, if this trick is really compatible with the vast majority of the players. Cross your fingers!

[jamos]

Great! So, it's definitively a good idea to leave the new option in PgcEdit, though I still think that this option should be used with caution. I'm pretty sure it will not work on some players.
What does superbit say? They use seamless breaks (as well as special-muxing which we are not doing, maybe mpucoder can come up with a way to do the special bitrate remux?). I think with newer players you will not have issues.

I'm trying to get my old Sony player (one of the first DVD players on the market) back from a friend to test it with my disks. Older Toshiba players always seem to be the pickiest on Burned media. It would be nice to get some feedback from others.

You could put up a warning dialog box the first time you check the option if your worried about it. But, please not every time I burn..hehe

[r0lZ]

Yes superbit is a good example, but, as you said, superbit DVDs are specially muxed to be compatible with most players. In PgcEdit, you can select any cell, including those that are probably not suitable, at least for old players.

There is alrerady a warning in the description of the option, beside the checkbox. I think the pink background when the option is ticked is sufficient to warn the user!

[jamos]

Yes superbit is a good example, but, as you said, superbit DVDs are specially muxed to be compatible with most players. In PgcEdit, you can select any cell, including those that are probably not suitable, at least for old players.

There is alrerady a warning in the description of the option, beside the checkbox. I think the pink background when the option is ticked is sufficient to warn the user!
I agree..:p

[jamos]

If your problem is a total freeze when the player switch to L1, then it's probably caused by a bad disc, a bad burner, a player that doesn't like your media, or its laser is "tired". In any case, it's hardware related. The trick discussed here will probably not help you.

But if you experience only a little pause (approx 1 or 2 seconds), then it's absolutely normal, and the new option in PgcEdit can probably be used to remove it. However, you have to understand that this trick breaks the rules of the DVD-Video standard. With some players, especially old or picky players (like yours?), using this option could lead to even more problems. You have to try it to be sure.

Technical info: The "Seamless Joint" flag is used to specify that a cell must be played seamlessly with the last one. This means that you will not have a pause between the cells. The DVD-Video standard imposes that the cell used for the layer break position has this flag clear, and therefore cannot be played without the little pause. Normally, all cells of a PGC are seamless, except the first one, and the cell used for the layer break, but in some cases, it is also possible to find other cells with the seamless flag clear.
With many recent players, it is possible to leave the seamless flag set on the layer break, and therefore to play it seamlessly. Seems to work fine. Hence the new option in PgcEdit.
With some slow players with small buffers, you will still see a little pause (possibly shorter) but the player will continue normally.
However, if the player needs the seamless flag clear to properly handle the layer break, it can hang completely.
We will see, in the future, if this trick is really compatible with the vast majority of the players. Cross your fingers!
I agree FREEZES on layer break is usually a bad burn. Ritek DL media is junk, Get MCC media it is the best and probably the only good DL media available (Sold as Verbatim).

[laserfan]

I really appreciate your replies jamos and r0lZ--as usual I'm sure I need to experiment/work with this to understand it better.

I do believe that it's possible that the freezes I experienced were not due to a bad burn, but rather that I tinkered with the seamless flag myself in conjunction with a DVD-RB backup, i.e. I may have added the flag and my Sony player (relatively new) froze on it.

As I type this I can't remember how one tells if adjacent cells are "seamless" or not--forget the flag--is it simply & solely that the time code doesn't reset to zero?

[jamos]

I really appreciate your replies jamos and r0lZ--as usual I'm sure I need to experiment/work with this to understand it better.

I do believe that it's possible that the freezes I experienced were not due to a bad burn, but rather that I tinkered with the seamless flag myself in conjunction with a DVD-RB backup, i.e. I may have added the flag and my Sony player (relatively new) froze on it.

As I type this I can't remember how one tells if adjacent cells are "seamless" or not--forget the flag--is it simply & solely that the time code doesn't reset to zero?
I am not sure but try the new setting and see if it works better. There is not a layerbreak flag per se, as you look at the burned disk it looks as if there is no layer break (ie cells report 8 or 10 depending if the discontinutity is set or not). I am using rebuilder also so I do not beleive it has anything to do with your freezes.

But try the new way and see.

How are you sure it is not your burn? Post a scan if you can (ie if you have a newer nec, liteon, plextor or benq burner you can scan for errors). High PIFs are bad and sometimes do appear at the layer break from burns. Just because a disk verifys does not mean that it is a good burn.

Does it only freeze when you play with the layer break and not use PGCedit to set it?

[mpucoder]

As I stated earlier, setting the seamless flag when the multiplex is not seamless causes my Sony players to freeze. Do not set this flag unless the mux is seamless. Cells within a vob should be seamless (in fact, I don't know how to make them otherwise, they are just a change in the cell ID and a boundary for SRI pointers, but the mux is no different then any two adjacent vobu). Vobs can be joined either way. A good way to tell is to look at the audio pts, in a seamless joint it will be lower than vobu_s_ptm.
I lowered the priority of the special mux on my todo list as the seamless flag is the biggest part of the trick. However, it will happen.
To determine if the mux rate is suitable for interleave or LB look at the difference in SCR of the last NavPk and the next pack (should be video). A difference of 146 is the high mux rate (10.08), 184 is the low rate (8.0)

[jamos]

I have to say none of my tests were with a standard dual layer disk using its original layer break (as why would you need to mess with the layer break if your just doing a 1:1 copy as decrypter can keep it right where it is at?). My disks are merged titles remastered using shrink or recode2 to extract just the movie and adjust start and end frames, vob/ifo edit to create new ifos then vob extras strip, pgcedit to clean up the extra chapter breaks, then dvd-rebuilder pro to encode to correct size, then pgcedit to burn. All cells are seamless except for the first cell of the title of course. I would say unless you have a dvd that is configured this way as mpucoder has stated do not use seamless layer breaks.

[blutach]

I have an old SONY NS300. Will do a test. Wish me luck.

(Note - I'll try to break at a change in VID and mark it with a 10 flag).

Regards

[r0lZ]

Good luck, blu! ;)

[blutach]

OK - results. Works fine on SONY and NAD (both of which are mean for spec compliance IMO). Very refreshing to have this, but I am still very nervous - especially given mpucoder's comments and experience with his players, which I am loathe to ignore.

Will continue to monitor on next few DL burns. I would want to ensure it works every time. So, I agree that it's a good idea to keep the pink warning in there r0lZ.

Regards

[r0lZ]

As I stated earlier, setting the seamless flag when the multiplex is not seamless causes my Sony players to freeze. Do not set this flag unless the mux is seamless.
Do you mean that you cannot set the seamless flag on non-seamlessly multiplexed cells, even on a cell that is not used for the layer break? Seems strange. The seamless flag is set automatically by most reauthoring tools like DVD Shrink, and, as far as I know, it has never caused problems.

[jamos]

Do you mean that you cannot set the seamless flag on non-seamlessly multiplexed cells, even on a cell that is not used for the layer break? Seems strange. The seamless flag is set automatically by most reauthoring tools like DVD Shrink, and, as far as I know, it has never caused problems.
I thought he meant he took a existing layer break and made it seamless (which maybe the layer break flag was removed when ripped and now it shows up as a 8 or 10, but was specially multiplexed for a layer break) or he took a non seamless cell (ie flagged 2) and tried to make it a seamless layer break. That would be the only issues I would see.
setting the seamless flag when the multiplex is not seamless causes my Sony players to freeze. Do not set this flag unless the mux is seamless
This is what I go by using PGCedit to check, if the original cell (look at the original disk for this) is flagged 8 or 10 (ie nonseamless) then using seamless layer breaks in that position should work. If you are setting the new layer break at the original layer break and the orignal layer break is at the start of a new VOB (even if now it is marked as seamless due to a program such as shrink or decrypter removing the layer break flag), or a non seamless break (ie flagged 2), then you want to put a non seamless layer break on that cell.

Also as in my case using vobedit to merge vobs and ifoedit to mock strip, I remove the multiplexing I think (even at my disk merge points) so I really do not have to worry about this as all my cells are flagged either 10 or 8 and after this process in my vts. And as stated in a above post I do have a seamless layer break at the merge point of the second disk and have no issues on playback.

[r0lZ]

I agree, but it's difficult to automate that in PgcEdit. The only thing I can test easily it a VOB ID change.

[mpucoder]

The situation where I tried setting the seamless flag and ended up hanging my players was at a new vob that was not seamlessly muxed.

[jamos]

OK - results. Works fine on SONY and NAD (both of which are mean for spec compliance IMO). Very refreshing to have this

Regards
Great BLU!

Funny how a simple question like my original post can turn into something like this... :p

[jamos]

The situation where I tried setting the seamless flag and ended up hanging my players was at a new vob that was not seamlessly muxed.
Ok thanks that makes it clear, yes I can see that causing issues.

[jamos]

I agree, but it's difficult to automate that in PgcEdit. The only thing I can test easily it a VOB ID change.
Maybe you do the timing calculations as mpucoder has stated and do not let them (or just warn them) set the break seamless based on high/low mux rate I think is what he is saying?

To determine if the mux rate is suitable for interleave or LB look at the difference in SCR of the last NavPk and the next pack (should be video). A difference of 146 is the high mux rate (10.08), 184 is the low rate (8.0)

If It were me I would leave it up to the user to determine this though..you have it marked as experimental and pink. Maybe pop up a warning dialog box if the mux rate is not right at burn time?

[mpucoder]

I'd suggest testing for the mux rate and altering the message accordingly. If the high rate is used the current warning is appropriate. But if the low rate is detected then it is apparent that the authoring prepared a point for the LB.

[bigotti5]

Strange, strange.....

Played around with scenarist

Created a track, inserted a couple of scenes, dropped the track into a VTS, manually set one cell to non_seamlessly, muxed .......the result is a NSM flag but the mux itself seems to be seamlessly (comparing audio PTM and VOBU_PTM as suggested)

So I set a layerbreak in scenarist, flag is changed to NSM automatically by scenarist, muxed but same result as above...the mux itself is seamless, only the flag is set to non_seamless

mpucoder, any comments?

[jamos]

I'd suggest testing for the mux rate and altering the message accordingly. If the high rate is used the current warning is appropriate. But if the low rate is detected then it is apparent that the authoring prepared a point for the LB.
yes if low rate is detected pop a warning saying 'This probably will result in a freeze at the layer break. please uncheck seamless break. Do you want to continue anyways?' or some such wording. Then maybe have a Ok and a Cancel button?

[jamos]

Strange, strange.....

Played around with scenarist

Created a track, inserted a couple of scenes, dropped the track into a VTS, manually set one cell to non_seamlessly, muxed .......the result is a NSM flag but the mux itself seems to be seamlessly (comparing audio PTM and VOBU_PTM as suggested)

So I set a layerbreak in scenarist, flag is changed to NSM automatically by scenarist, muxed but same result as above...the mux itself is seamless, only the flag is set to non_seamless

mpucoder, any comments?
Was the break at a new VOB?

[r0lZ]

I'd suggest testing for the mux rate and altering the message accordingly. If the high rate is used the current warning is appropriate. But if the low rate is detected then it is apparent that the authoring prepared a point for the LB.
Thanks for your advice.

I'll try to do it, but PgcEdit being essentially an IFO editor, I haven't the functions to retrieve the necessary information in the VOB yet. Seems easy, though.

[mpucoder]

@bigotti5 - Scenarist will let you change a cell to NSM but that does not change the mux. Only vob to vob (track to track) have a distinction in the mux. A non-seamless cell will pause, and allow execution of the previous cell's cell command.
@jamos - just the opposite, the low rate is recommended for layer breaks.

[laserfan]

I had mentioned a freeze on one of my discs:

I am not sure but try the new setting and see if it works better...Does it only freeze when you play with the layer break and not use PGCedit to set it?It turns-out that in my original post the disc I was thinking about (the one that froze) was not a dual layer disc at all--it was a single layer disc that had been rebuilt by DVD-RB Pro. :o

I regret having made that post and will try to be more careful before I "open my mouth" again.

[bigotti5]

@bigotti5 - Scenarist will let you change a cell to NSM but that does not change the mux. Only vob to vob (track to track) have a distinction in the mux. A non-seamless cell will pause, and allow execution of the previous cell's cell command.

It is not the seamless mux at NSM flag set manually surprising me, but even set a layerbreak causes a seamless mux.

So set a layerbreak in scenarist will result in a seamless mux with the NSM flag set, unless it is set on a track boundary and set the NSM flag on a seamless cell does not violating the spec nowise.
Until now I presumed a NSM flag claims a non_seamless mux to be accurately in specifications

thx

[jamos]

@jamos - just the opposite, the low rate is recommended for layer breaks.
I think that was what I was asking? did he create the break at the start of the VOB boundry? which I DO NOT think he did which is why it was the high rate and normal mux (it just changes the flag), if he created the layer break at the start of a new VOB I would think Scenarist would mux at the lower rate. Am I right or have this reversed?

[jamos]

I had mentioned a freeze on one of my discs:

It turns-out that in my original post the disc I was thinking about (the one that froze) was not a dual layer disc at all--it was a single layer disc that had been rebuilt by DVD-RB Pro. :o

I regret having made that post and will try to be more careful before I "open my mouth" again.
Hehe ok well I am sure depending on the ENCODER, filters, and matrixes you use that Rebuilder can have issues with freezing etc. (still could be a bad burn though). I use procoder2 quality is excellent and no matrixes or filters to worry about, but it is expensive.:(

[mpucoder]

It is not the seamless mux at NSM flag set manually surprising me, but even set a layerbreak causes a seamless mux.

So set a layerbreak in scenarist will result in a seamless mux with the NSM flag set, unless it is set on a track boundary and set the NSM flag on a seamless cell does not violating the spec nowise.
Until now I presumed a NSM flag claims a non_seamless mux to be accurately in specifications

thx
Again, cell to cell has no seamless/non-seamless form of mux, only vob to vob.

[mpucoder]

That was in response to:
yes if low rate is detected pop a warning saying 'This probably will result in a freeze at the layer break. please uncheck seamless break. Do you want to continue anyways?' or some such wording. Then maybe have a Ok and a Cancel button?

[jamos]

That was in response to:
ok so a high mux rate means that a vob layer break boundry is coming up?

[mpucoder]

The high mux rate is the normal mux rate, it gets lowered to 8.0 before a seamless branch, multiangle ILVU, or a Superbit LB. Lowering the mux rate means more time for refocusing the laser.

[jamos]

The high mux rate is the normal mux rate, it gets lowered to 8.0 before a seamless branch, multiangle ILVU, or a Superbit LB. Lowering the mux rate means more time for refocusing the laser.
Ok then I understood that backwards.:eek:

All my VOB cells are high rate and I have no issues on any Sony players with seamless (3 of them ranging from old to very new). Are you saying you did have issues with high rate and seamless breaks?
http://img56.imageshack.us/img56/2692/mux9jh.png (http://imageshack.us)

P.S. I joined your site mpu..look forward to reading more about this stuff.. :p

[bigotti5]

You shall compare the SCR-Values (offset 0004, not 000a) of the Navpack and the first following Videopack.
If Video pack shows a value 184 higher it is at low mux rate, at high bitrate the value will be 146

[mpucoder]

Right, the declared mux rate at offset 0x0a is always 10.08
This particular example is the second vob of a multistory DVD (T2 Extreme)

[mpucoder]

All my VOB cells are high rate and I have no issues on any Sony players with seamless (3 of them ranging from old to very new). Are you saying you did have issues with high rate and seamless breaks?
Nope, but lowering the mux rate helps older players recognize that buffer cramming is needed. Also the lower mux rate guarantees a lower data rate, if the multiplexer can't pack all the data in at the lower rate it will complain. But in the end, it is the lower data rate that allows the player to fill the buffers and not run out of data while refocusing. Newer players have larger buffers and better buffer management. It is the older players that need a hint (the mux rate) to speed up data recovery.
Which, when you think about it, is contrary. Here we lower the mux rate to encourage the player to increase the data reading rate.

[blutach]

Just thinking, for DVDs that have a VOB ID change at the LB.

Would it be possible to use VID Changer to change the VIDs to all one VOB ID, demux and remux all seamless?

Might this tend to ensure a 184.1 SCR change and always enable a safe seamless layer break?

Or are there plans for muxman to be able to do this without a VID change?

Regards

[mpucoder]

Would it be possible to use VID Changer to change the VIDs to all one VOB ID, demux and remux all seamless? not necessary for seamless joints, virtually all authoring programs can make seamless vob joints.
Might this tend to ensure a 184.1 SCR changeNo, this rate is used only for interleaved vobs (multi-angle or multi-story) or by Superbit for seamless layer break.
Or are there plans for muxman to be able to do this without a VID change?Yes

[r0lZ]

OK, PgcEdit_winexe_7.0.1_beta3 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_7.0.1_beta3.zip) is ready.
I have added a check to avoid the problem explained by mpucoder.

Here is exactly what I do:

If the LB cell has its seamless flag set and if its VOB ID is different than the VOB ID of the previous cell, I get the SCR of the first nav pack of the LB cell, and the SCR of the next pack (normally a video pack, but that is not checked.)
If the difference between the 2 SCRs is 146, then a warning is issued, and the user has the choice of leaving the seamless flag set (at his own risk), to clear it (the default option), or to cancel the burn to select another cell.

When the VOB IDs are identical in the LB cell and the previous one, the warning is not displayed and the seamless flag is left as it is.

Of course, the seamless flag is always cleared if the main option is not checked in the LB Selection dialog.

I have also changed the pink message.

Let me know if it's the correct way to do it. Thanks.

[jamos]

Here is exactly what I do:

If the LB cell has its seamless flag set and if its VOB ID is different than the VOB ID of the previous cell, I get the SCR of the first nav pack of the LB cell, and the SCR of the next pack (normally a video pack, but that is not checked.)
If the difference between the 2 SCRs is 146, then a warning is issued, and the user has the choice of leaving the seamless flag set (at his own risk), to clear it, or to cancel the burn to select another cell.
.
Shouldn't it be the difference between the previous navpack in other vob and the layer break navpack? not the next one? I thought the cell previous to the layer break is the cell that is muxed lower?

[bigotti5]

The last 3 or 4 navpacks from previous cell and the first three or four navpacks of the layerbreak cell should be at low mux rate

[r0lZ]

OK. So, my method is correct?
Or do I have to test also the SCR reset?

[bigotti5]

not sure but imo it is not needed to check VobIDs, only the mux rate 2 seconds before and after the break is important

mpucoder
That is the multiplex rate is slowed to 8Mbps (instead of the normal 10.08) for a minimum of 2.5 seconds before AND after the break (like a PREU), and the audio buffers are starved (loaded with data as late as possible rather than the normal as soon as possible) as in any seamless joint

[r0lZ]

Not sure. Since the cells within the same VOB are always seamless, I don't test them. I always accept a seamless LB if it is set at such a cell. Is it right?

[bigotti5]

Since the cells within the same VOB are always seamless

imo the mux itself should always be seamless to set a seamless LB, regardless of changing VobID or only CellID

lower mux rate helps the player to refocus without buffer problems

[bigotti5]

@rolz

do you want to check if the mux of a Vob change is seamless?

if so, you have to take a look to the PTM value of the first audio pack in the cell and compare with Vobu Start PTM (offset 0039 in navpack)

[r0lZ]

Hum, I'm feeling lost!

Do you mean that I need to test the mux rate also when the VOB ID doesn't change? Seems logical, but I thought it is necessary only for a new VOB cell.

When the cell is muxed at the lower rate, I don't think it is necessary to check if the mux of a VOB change is seamless. The low rate is sufficient to indicate that this cell has been muxed seamlessly, no?
Furethemore, how do you test the seamless joint if the cell has no audio? It's relatively frequent in menus.

[jamos]

Hum, I'm feeling lost!

Do you mean that I need to test the mux rate also when the VOB ID doesn't change? Seems logical, but I thought it is necessary only for a new VOB cell.

When the cell is muxed at the lower rate, I don't think it is necessary to check if the mux of a VOB change is seamless. The low rate is sufficient to indicate that this cell has been muxed seamlessly, no?
Furethemore, how do you test the seamless joint if the cell has no audio? It's relatively frequent in menus.
Personally, I would just leave it like beta2. Take out the check altogether. I am not having issues with seamless and high mux and it looks like blu isnt either. I believe the only issues that MAY cause lockups (no one has confirmed this using your tool to set seamless yet. mpu has said he had a lockup though doing it himself) are with some older dvd players, which even my old 1998 sony dvd player has no issues with my disks and seamless breaks. Seems like much work on your part when you basically already warn them in the message in beta2.

As far as the vob change I do not know if that matters..But if you want you can pop up a message (like you do in beta3) if the rate is high and a seamless break is selected (no matter if a vob change has occurred). Your right about the low check, low is meant for seamless so then no warning message for seamless or non seamless break should work if its the low rate.

[mpucoder]

Doesn't matter if it's a new vob or not, the mux rate being lowered reduces the chance of a buffer underrun and a pause.
It is simpler to look at the SCR difference both before and after the LB. My screenshot was of a new vob only so you could see the SCR value of the video was 184.096. If I could show both the NAV and the next pack I would have done the screenshot on the previous vobu - shortcoming of VobEdit. (and I didn't want to upload 2 images).
I had forgotten about the other trick being used - audio buffer starvation (and no audio frames spanning the 2 vobu's). That happens normally at a seamless vob joint. To be complete I'm going to have to add the ability to do this between cells, along with the mux rate change.
With modern players the key is the seamless flag. These players already manage their buffers well, read much further ahead than the model requires, and pause only because they are told to (non-seamless).

[jamos]

Doesn't matter if it's a new vob or not, the mux rate being lowered reduces the chance of a buffer underrun and a pause.
It is simpler to look at the SCR difference both before and after the LB. My screenshot was of a new vob only so you could see the SCR value of the video was 184.096. If I could show both the NAV and the next pack I would have done the screenshot on the previous vobu - shortcoming of VobEdit. (and I didn't want to upload 2 images).
I had forgotten about the other trick being used - audio buffer starvation (and no audio frames spanning the 2 vobu's). That happens normally at a seamless vob joint. To be complete I'm going to have to add the ability to do this between cells, along with the mux rate change.
With modern players the key is the seamless flag. These players already manage their buffers well, read much further ahead than the model requires, and pause only because they are told to (non-seamless).
Look forward to this as I would like to make my dvds as complient at possible. Will pitch in the extra 5$ to get muxman when you do :p

[jamos]

Doesn't matter if it's a new vob or not, the mux rate being lowered reduces the chance of a buffer underrun and a pause.
It is simpler to look at the SCR difference both before and after the LB.
Ok while your changing PGCedit to look at the previous cell Rolz and since your looking at the vobs now, can you mark the seamless break somehow to show in PGCedit by looking at the vob info?? :devil: hehe..j/k would be nice though :p

[r0lZ]

Thanks everybody. Everything is clear now.


Jamos, that was just my idea. Since it is necessary to test also the mux rate of the cells within a VOB, it is probably easier to test all cells before displaying the GUI, and mark the cells with low rate in colour, or with a flag in a new column. Also, in this case, I can easily change the pink warning message according to the currently selected cell.

BTW, maybe you could change the title of this thread to more closely reflect its current subject.

[r0lZ]

PgcEdit_winexe_7.0.1_beta4 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_7.0.1_beta4.zip)

Now, the mux rate is tested on all cells, and displayed in the GUI.
The warning is pink only if the current cell has its seamless flag set and is muxed at high rate. The yes/no/cancel confirmation dialog has been removed.
I have also modified the messages in the description of the coloured lines and the pink warning.

The seamless mux is still not tested when the VOB ID changes.

Your comments will be appreciated...

[jamos]

Is my definition of mux matching others here?
High mux = Non Seamless Mux (normally requires a non seamless break)
Low mux = Seamless Mux (expecting a seamless layer break, or interleave, or multistory)

[r0lZ]

No. If I have correctly understood, high rate mux is the standard way to mux seamless cells. The low rate is used when the cell is seamless but the laser has to refocuses after a position change (like in an ILV cell, or at the LB position.)
BTW, this is why I wonder if I have to test also if the cell is seamless.

[jamos]

Ok does everyone agree with this then?
High Mux = Seamless Mux (normally requires a non seamless break)
Low Mux = NON Seamless Mux (expecting a seamless layer break, or interleave, or multistory)

But this confuses me on the issue.
MPU has said this:

As I stated earlier, setting the seamless flag when the multiplex is not seamless causes my Sony players to freeze. Do not set this flag unless the mux is seamless. Cells within a vob should be seamless (in fact, I don't know how to make them otherwise, they are just a change in the cell ID and a boundary for SRI pointers, but the mux is no different then any two adjacent vobu). Vobs can be joined either way.

[r0lZ]

I have made some tests with commercial DVDs, and found this strange situation (in Ark, french edition, Z2.)

http://img451.imageshack.us/img451/102/vobchangenotusedforlb2zf.png (http://imageshack.us)

The VOB ID changes at cell 6, but cell 7 is used for the original layer break! (The seamless flag was clear on cell 7.) Note that cell 7 is the only one that is muxed at low rate.

[EDIT] BTW, Bigotti, in reply to your sentence "To see low mux rates on other cell/vob changes you have to take a look at superbit layerbreaks or to wait for a future version of muxman." in the next post, this is a good example of low mux rate, used for the LB in a seamless cell. And it's not a superbit DVD. I don't understand why they used the low rate together with the seamless flag clear, though. Just to be standard compliant? And why is it a VOB ID change? Seems useless...

[bigotti5]

High mux = Non Seamless Mux (normally requires a non seamless break)
Low mux = Seamless Mux (expeciting a seamless layer break, or interleave, or multistory)

High mux does not mean a non_seamless mux.
All available authoring soft does a high mux rate on a VID change if you set it seamlessly (and is muxed as a cell change).
The mux rate is lowered only if VID change is caused by multiangle, multistory or seamless branching.
To see low mux rates on other cell/vob changes you have to take a look at superbit layerbreaks or to wait for a future version of muxman.

[r0lZ]

@Jamos:
No again, IMO, low and high mux can be used in seamless cells (and probably as well in non-seamless cells.) The low mux is necessary only when the laser has to refocuses. This doesn't mean that the cell is not seamless.

[EDIT: Bigotti was faster!]

[mpucoder]

mux rate and joint type are independant, although it would be senseless to lower the mux rate (to enable interleaving) and not use seamless muxing.
@r0lZ - the mux rate can change within a cell, it is the mux rate before and after a cell/vob change that is of interest.

[r0lZ]

Thanks for the precision, mpucoder. Of course, that's what I mean.

[jamos]

High mux does not mean a non_seamless mux.
All available authoring soft does a high mux rate on a VID change if you set it seamlessly (and is muxed as a cell change).
The mux rate is lowered only if VID change is caused by multiangle, multistory or seamless branching.
To see low mux rates on other cell/vob changes you have to take a look at superbit layerbreaks or to wait for a future version of muxman.
thanks.

[bigotti5]

just to clarify I made an image about seamless and non_seamless mux

this is independant from the mux rate

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

[r0lZ]

Great, Bigotti!

To clarify also, I summarize what I've learned.

1) When the VOB ID doesn't change:
- The cell is always seemless.
- The cell can be muxed at low or high rate.
- The cell can be used for the LB position.
- It is always possible to use the "seamless flag set on LB cell" trick. A player will always be able to play it, but an old player will probably still show a little pause, especially if the mux is at high rate.

2) When the VOB ID changes:
- The cell is seemless or not.
- The cell can be muxed at low or high rate.
- The cell can be used for the LB position.
- It is possible to use the "seamless flag set on LB cell" trick only if the cell is seamless, or some old players will hang.
- If the low mux rate is used, this means that the cell is probably seamless, and therefore the seamless flag on LB trick should work.

As you can see, the last point is still somewhat obscure to me. Do I need to test if the cell is really seamless in this case?

[bigotti5]

And it's not a superbit DVD. I don't understand why they used the low rate together with the seamless flag clear, though. Just to be standard compliant?

I think so

Here is a statement of Mark R. Johnson (Co-Author of DVDDemystified 3rd Edition, Still in motion,Technicolor) in Tully DVDlist forum

Well, the DVD Specification requires that the layer break begin at the start of a non-seamlessly linked Cell. This does not necessarily have to be a chapter point..........

[bigotti5]

If the low mux rate is used, this means that the cell is probably seamless, and therefore the seamless flag on LB trick should work.

It does not make sense to me to lower the mux rate on a non_seamless cell so I think it should work

[r0lZ]

Well, the DVD Specification requires that the layer break begin at the start of a non-seamlessly linked Cell.
However, this rule seems to be violated very often! I have many commercial DVDs with the layer break at a cell that is not at the beginning of a VOB (including in my Ark example above (http://forum.doom9.org/showpost.php?p=822011&postcount=119).) Since those cells are always seamless, there is obviously a problem.
If this rule is violated so often, I think we can consider that the rule is obsolete! Or is it possible to do non-seamless cells inside a VOB? That's not what mpucoder says. :confused:

[bigotti5]

Or is it possible to do non-seamless cells inside a VOB? That's not what mpucoder says

No - mpucoder stated a cell change is always seemless

I am sure if you compare the PTS of first audio pack in your Ark example it shows a value < than Vobu Start Presentation Time (offset 0039 in Navpack)

[mpucoder]

Well, the DVD Specification requires that the layer break begin at the start of a non-seamlessly linked Cell. refers to the flag in the PGC, not the mux - the keyword is "linked"

[r0lZ]

refers to the flag in the PGC, not the mux - the keyword is "linked"
Ah, OK, that makes sense. Although here, in this thread, we are discussing the way to not respect this rule! ;)

[jamos]

refers to the flag in the PGC, not the mux - the keyword is "linked"
So the LB cell can be seamlessly (or non seamlessly) muxed but not seamlessly linked..jeesh this is more confusing than dvd hardware...:scared: And we are talking about violating the rule here..in essence superbit is violating it.

[mpucoder]

I'm beginning to believe the specification has been once again misunderstood (plenty of that happened as the original documents were the typical result of a commitee, further enhanced by a bad translation to English from the original Japanese). And fortunately the hardware designers said "why not - we can handle this" (seamlessly changing layers)
It would not surprise me to learn that the original intent of the rule was to prohibit a layer break during an interleave such as multi-angle or a story hop. Technically the bit in the PGC is not a link, but there are seamless links in the DSI part of a NavPk. There are also links in the PCI part for what is called a "non-seamless multi-angle" - which really means a multi-angle interleave that the user is not free to change during playback.
It would make a lot of sense, in 1995, to not require players to perform a layer break and allow the user to change the angle at the same time, hence a layer break with a "non-seamlessly linked cell"

But this is just conjecture on my part - I've never had the opportunity to have a native Japanese speaker look at the original.

[jamos]

Hey Rolz does PGCedit beta4 not show seamless breaks? Or is that on your to do list? I thought by looking at the VOBs you could see where a seamless break occurs..is this not true? Currently I still cannot see where the layer break is with PGCedit looking at a burned title on a seamless break burn.:confused: cells are muxed normally (ie high). Break is on a new VOB.

[r0lZ]

What do you call "seamless break"?

I have added only the check of the low/high mux rate.
Checking if the cell is seamless or not is a little bit more difficult, especially if there is no sound track. I could add it, but seems it's not very important. According to Bigotti, if a cell is at the beginning of the VOB and is muxed at low rate, we can assume that it is seamless. Otherwise, the cell is probably not seamless, and the seamless flag should be clear, or mpucoder's player will crash! ;)
BTW, I have changed again the pink background of the warning. Now, it is pink only in this latter case. The message is also more precise.

BTW, mpucoder or Bigotti, can we assume that, when there is no soundtrack, the cells are always seamless?

[bigotti5]

Checking if the cell is seamless or not is a little bit more difficult, especially if there is no sound track.

Imo if there is no soundtrack there is no seamless or non_seamless mux. The audio buffer cant underrun.

[mpucoder]

BTW, mpucoder or Bigotti, can we assume that, when there is no soundtrack, the cells are always seamless?
No sound and no subs results in very little difference. But there is a detectable difference, the first PTM will probably not be the same as that used in the very first vob, which is an arbitrary number (usually 25257). This is not so easy, though, as there are differences among multiplexers as to the value used for the first vob. Also the method of calculating the new value differs amongst multiplexers.

[mpucoder]

I just thought of an easier way to detect seamless vob joints. The preceeding vob in a seamless joint cannot have a sequence_end header, while a non-seamless should. And you don't need to parse the video stream to look for it as the last NavPk has a field for the sequence_end ptm (vobu_se_e_ptm at offset 0x41).
When it comes to cells this field can be non-zero if there is a still picture (slideshow style, ie with audio). And before anyone asks a seamless joint cannot follow a slideshow because of the need for a sequence_end.

[jamos]

What do you call "seamless break"?

I have added only the check of the low/high mux rate.
Checking if the cell is seamless or not is a little bit more difficult, especially if there is no sound track. I could add it, but seems it's not very important. According to Bigotti, if a cell is at the beginning of the VOB and is muxed at low rate, we can assume that it is seamless. Otherwise, the cell is probably not seamless, and the seamless flag should be clear, or mpucoder's player will crash! ;)
BTW, I have changed again the pink background of the warning. Now, it is pink only in this latter case. The message is also more precise.

BTW, mpucoder or Bigotti, can we assume that, when there is no soundtrack, the cells are always seamless?
I was talking about showing the seamless layer break position (ie layer break with the seamless flag on) on the disk. I thought you said something about adding a special column on the break postition to show it when you open the title. no big issue thought maybe it was possible to see from the VOBs. This has nothing to do with muxing just when I read a disk that I used PGCedit/imgtool to burn with to find the layer break (currently setting the layer break seamless shows no layer break).

[bigotti5]

And before anyone asks a seamless joint cannot follow a slideshow because of the need for a sequence_end.

I made an example in maestro, 00 01 B7 is present, Vobu_se_e_ptm is non zero but the following vob joint seems to be seamless if I compare audio PTS values


http://rapidshare.de/files/19500930/Seam_Vob_Mux.rar.html

[mpucoder]

That's not what I see. Both vob 2 and vob 3 (there are two angles) do not have vobu_se_e_ptm set in the last vobu, and the sequence_end was replaced with 00's. Besides, this is not what Scenarist calls a slideshow (I know, the term is not very specific). I was referring to a single I picture extended in time, as in my 7 color subpicture example.

edit: Maybe you were talking about vob 1? It doesn't look very spec, I'll see what the verifier says. For a vob prior to angles the last 3 or 4 vobu's should be marked as PREU, but they are not. The mux rate is OK, though.

[mpucoder]

Wow, lots of errors, including
>>> [DVD] ERROR 4621 (ref. DVD-3 4.5.2 (1)) :
SML_PBI : VOB is allocated in a Contiguous Block and connected seamlessly
with the next VOB in an Interleaved Block, and the former VOB is not defined as PREU.
for DSI unit 10 at byte 48 bit 0;
PES stream-byte 20148 (byte 1072 of packet 19);
PS stream byte 198704 (byte 2096 of pack 96).and
>>> [DVD] ERROR 4644 (ref. DVD-3 5.1.1) :
SML_PBI : The VOB_V_E_PTM value 1033200 (11.480 seconds) must be the
same as the VOBU_E_PTM 475200 (5.280 seconds) of the last VOBU.
for DSI unit 9 at byte 48 bit 0;
PES stream-byte 19131 (byte 55 of packet 19);
PS stream byte 183351 (byte 1079 of pack 89).

The verifer does not check for a still before a seamless joint, but in my tests and research I discovered it does not work properly. However, we cannot discount the fact that many authoring programs (MuxMan included) will allow a still before a seamless joint.
This example brings up another subject - interleaving and the layer break. I believe the original intent of the rule about "seamlessly linked" was referring to interleaving. And it would be asking a lot of a player to not only refocus but start de-interleaving at the same time. It is my opinion that LB should not be allowed if either vobu is marked as interleaved (offset 0x427 non-zero)

[bigotti5]

Maybe you were talking about vob 1?

Yes, talking about vob1

Besides, this is not what Scenarist calls a slideshow

Why not?
Cant see the difference..

Interra tells
Error Name: N-DSI-2-040 Severity: Minor Error in: Data Search Information(DSI)
Error: Error in DSI playback information
Location:
Description: VOB termination time is not same as presentation termination time of last Video frame of the last GOP.It should be 475200 which is VOBU_E_PTM in last VOBU but it is 1033200
Specification Page Number: V14-139



just an example what is possible with an approved app as spruce :)

[mpucoder]

That was in reference to vobs 2 & 3, vob 1 is indeed a slideshow.
I'm surprised that is considered a minor error, maybe based on how badly it affects players. It definitely causes problems with several demuxers (PgcDemux, DVDSubEdit, the internal demuxing/positioning of MuxMan).

But back to seamless LB - A very strong warning should be given if the vobu either before or after a proposed LB is interleaved.

[jeanl]

mpucoder, this is a very interesting thread, especially the part about the seamless playback flag in the IFO.
Now, this brings another question: How is this flag used by the player???
From what you say, the player can play a seamless transition even if the flag isn't set, but setting the flag is the joint isn't muxed seamlessly can crash some players...
So how do players use the flag?

jeanl

[mpucoder]

Looks to me like the flag tells the player how to play. If it's set the player attempts seamless playback, if it's clear the player lets all buffers run out and checks for a cell command.

[jeanl]

Ok, that makes sense. So if I understand you correctly, if the flag isn't set, even though the joint is muxed seamlessly, you will still have a pause in the playback.
In other words, to get a seamless playback you need both a seamless mux and a set flag.
Jeanl

[jamos]

Ok, that makes sense. So if I understand you correctly, if the flag isn't set, even though the joint is muxed seamlessly, you will still have a pause in the playback.
In other words, to get a seamless playback you need both a seamless mux and a set flag.
Jeanl
I have normal mux and i set the seamless flag option in PGCedit, no pause on break. Some players (older ones) may have issues with small buffers running out of memory and you would get a pause (as with non seamless break), but most (if not all) newer ones will not have issues. In PGCedit we are setting the layer break flag and we are just leaving the joint flag seamless (either 8 or 10). Note: I am only talking about seamless cells here not interleave etc.

and yes even if you have seamless mux and the layer break flag is set normally it is a non seamless break and you will get a pause.

[r0lZ]

A very strong warning should be given if the vobu either before or after a proposed LB is interleaved.
OK, I have added a warning, and the pink background in this case. Currently, this warning is issued if the First ILVU End value in the cell playback info table is non-zero for the current cell or the previous one. Is this test sufficient?

Note that, currently, it is not possible to select an angle cell for the LB. It's mainly because I don't know if the seamless flag must be cleared on all cells of the angle, or only on the selected cell. I suppose it's the first case, but I don't have the logic to do that easily. Therfore, it's forbidden. :rolleyes:

However, it is possible to set the LB on the cell that follow an ILV or angle cell. Your advice is therefore useful, mpucoder. Thanks again!

[blutach]

Looks to me like the flag tells the player how to play. If it's set the player attempts seamless playback, if it's clear the player lets all buffers run out and checks for a cell command.And, I guess, to ensure the buffers are all clear, every now and again, we see the NOP cell command at the LB.

Regards

[mpucoder]

OK, I have added a warning, and the pink background in this case. Currently, this warning is issued if the First ILVU End value in the cell playback info table is non-zero for the current cell or the previous one. Is this test sufficient?
As long as you check all PGCs I'd say it is, as even single angle multi-story, which uses cell types 12 and 14 (interleaved but not an angle block), sets this value. Possibly the "interleaved" flag in the cell category would be easier to check?

[r0lZ]

Easier, no, but it's also easy. I can even check both the First ILVU End and the interleaved flag, but, since the user can change it in PgcEdit, I prefer to trust the ILVU End! ;)

[jamos]

Hey Rolz, not sure or not if this is intentional but if I have the layer break set on the title as non seamless IE 0 and the non seamless option turned on, it still burns non seamless...the seamless option does not override, hence to get a seamless break I would have to manually take out the layer break flag then burn. Is that intentional? If so can you disable the seamless option on burn if I have a non seamless break checked?

thanks

[r0lZ]

Yes, it's intentional. It's what is described in the text beside the option (at least in the current version.)
If I set the seamless falg, I have to test if the current VOB is really seamless, and can really be played seamlessly. (For exemple, I must also test if there is a cell command.)
A cell with the seamless cell clear appear in blue in the list. You can set the layer break manually on such cell with the "Seamless Cell" button, below the new option... but at your own risk.

I agree that it's not very intuitive, and maybe I'll change that in a future release (or beta?)

[Jenny Davis]

Hi guys

A lot of the previous discussion was over my head, but I think I understood that there are two mux rates and it is necessary to have the low mux rate going into a layer break. I would like to incorporate this on the DVD I am authoring but I also want to stay with DVD-lab pro and Gear Pro ME as my main authoring and mastering tools.

Is there a program that will let me set the low mux rate and also work with these two programs?

Will muxman do this?

Will making it multi angle just before the layer break force the lower mux rate?

Thanks for any replies.

Jenny

[mpucoder]

It is not absolutely necessary to lower the mux rate, but this is what Superbit does.
MuxMan is an authoring program, as is DVD Lab, one cannot do half the work for the other. The mux rate is determined by the multiplexer, which is at the core of every authoring program. To stay with DVD Lab it would need to allow lowering the mux rate without interleaving (the usual reason to lower it).
The current versions of MuxMan do not allow lowering the mux rate, that will be available in a future release.

[bigotti5]

...but this is what Superbit does.

Not always - I have a Superbit here with seamless layerchange at high mux rate

[mpucoder]

How about that - so it looks like the mux rate is really not very important at all.