ILV/multiangle VTS

[BigCondor]

I open a dvd and the following message was shown:-

VTS01: Detected 2 cells with pointers mismatch between VTS_C_ADT and PGC_PBK tables
Using VTSM_C_ADT initial and ending pointers...

This is quite usual in ILV/multiangle VTSs, but VobBlanker does not support them, except in skip mode.

Note: This is NOT an InterLeaVed VTS

And the Initial and Final Size are 7623 and 7617 respectively.

So, what the difference between ILV/multiangle VTSs and InterLeaVed VTS?

I want to remove some warning themes from the menu. I see there is difference between the Initial and Final size. If I blank out the warning themes will it affect the VTS01 cells?

[r0lZ]

ILV means InterLeaVed. ILV is a generic term used for both multiangle and multistory PGCs.

You should always avoid processing the title domains with ILVed cells with VobBlanker, but you can safely skip them.

Also, it is possible to remove the angles with DelAngles or PgcEdit, or to remove or blank all multistory PGCs but one with PgcEdit, and process the VTS with VobBlanker. This subject has already been covered several times. Use search...

[BigCondor]

Thanks for the reply, but when I open the dvd in PgcEdit, I don't see any extra angels. When I press del angels it reports the program is not multiangel. But DVD Shrink does report there are 2 angels.

[r0lZ]

Be sure to inspect all PGCs of the title domain. If you can see a non-zero First ILVU End value in the cell table of the PGC Editor, then that PGC is ILVed. The angle for each cell is also displayed in that table, but as you know now, an ILVed PGC can have only one angle, if it is multistory.

[BigCondor]

I don't see any non-zero First ILVU End value in the cell table, but I do see the Entry VOBU sector of the last cell (3872) and End (4333) is much smaller than that of the previous cell (Entry 3499876, start 3614479, End 3614570) with the cell type 2. Is that the cell tha matters?

[r0lZ]

No, that's probably normal, especially if the last cell is a tiny one.

Are you sure you have verified ALL PGCs of the domain(s) rejected by VobBlanker? If it's the case, that might be a bug in VB, or it detects ILVed cells in the VOB files, although they are not referenced in the IFOs. I don't understand. Anyway, I suggest you backup your files, and try to process them with VB. If you are right, everything should be fine. Burn a RW to verify if there are no pauses during the playback!

[blutach]

Your message is that is is NOT an ILV'ed DVD - PgcEdit won't find any angles on this DVD, that's for sure. What you are getting is a couple of cells with different entry sectors in the cell tables to the PGCs. VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) is warning you, that's all.

As well, the recent beta of VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) will tell you exactly where the mismatches are.

Note: This is VERY usual on recent ARccOS DVDs.

Regards

[r0lZ]

You're right, blu! I haven't read the warning message carefully enough!

[blutach]

You're right, blu! I haven't read the warning message carefully enough!One of the rare occasions mon ami!

Bon nuit!

Regards

[r0lZ]

It's not the night in Belgium yet! Mais bonne nuit à toi!

[BigCondor]

Thanks guys, so probably it is caused by protection.

[blutach]

No, the warning is probably benign. See with the new VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) what PGCs it refers to. Then check whether they are even played in PgcEdit. Even so, I do not believe it is illegal in entering a cell at a later point than its start point - after all, that is what the VOBU plugin in PgcEdit is all about.

Regards

[BigCondor]

Thanks for the advice, I'll get the new VobBlanker tonight after work and check again.

[blutach]

Get the Beta (8) - see thread in this forum for link

Regards

[BigCondor]

Thanks, I was half way thru the thread before I engaged in my daily work, and now I have time to continue. It is quite interesting like reading a story without stopping!

[jsoto]

I do not believe it is illegal in entering a cell at a later point than its start point - after all, that is what the VOBU plugin in PgcEdit is all about.
I agree.

Currently VobBlanker outputs the same cell entry (and last) pointers in VTS_C_ADT and in all playback tables where the cell is included. It uses the ones from VTS_C_ADT.
May be I should change VobBlanker's behavior to honor these gaps, at least in Keep mode..., but not so easy, because how VobBlanker works internally. I'll look into it.

jsoto

[blutach]

If you honour it, then some unreferenced material will be kept - a la the jumping boy.

But the new smart gaps creates this anyway :) (by the way, it is working very well)

Regards

[BigCondor]

Just had the dvd run in 2.1.2.0b8, there was another message showing that a PGC can be marked as one_seq, and the pgc is VTS01 PGC 003. And then, the pointers mismatch are cells 1 and 2 of that Pgc. So, after all, it's not the main title that matters!
Just wonder what's for with one_seq?

With the new version, it is much more easier to locate the problem, life is easier with your wonderful tools, thanks!

[jsoto]

Just wonder what's for with one_seq?That means this PGC can be marked as one_seq_TITLE_PGC, so filling the TMAPTI, you'll be able to use navigation functions like "goto" or the slider in PowerDVD/WinDVD. As there is no drawback at all, VobBlanker will mark it as one_seq, and its TMAPTI will be filled.

If you honour it, then some unreferenced material will be keptNot always. Imagine one cell used in two PGCs. One PGC can use the whole cell, and the other one only part of it. In this case, there is no unreferenced material.
Honestly, I think this can be qualified as bug, because VobBlanker has to honor the playback pointers, as it is what the settop does. If not, the settop will play some VOBUs that are not intended to be played...

jsoto

[r0lZ]

I agree, but I'm still wondering if that method is really standard compliant. IMO, you should add an option if you change the current behaviour, or at least issue a warning in the log.

[jsoto]

I agree, but I'm still wondering if that method is really standard compliant. IMO, you should add an option if you change the current behaviour, or at least issue a warning in the log.Me too. Probably it is not standard compliant, because you're pointing to a middle of a cell (so elapsed time will not start at cero in this "pseudocell", playback time of the PGC cannot be correct, not sure what will happen if you go backwards from the remote, because of internal VOB pointers....etc) . In summary, it is the same case if you split a cell into two in the IFOs, changing only the VID/CID in the VOB. VOB internal pointers point out of the cell, elapsed times are not correct, etc

So, I don't know if I'm going to do something or not, but in any case, the warning will be there, and the user will have the option to use the current behavior.
jsoto

[blutach]

In many recent DVDs, these pointer mistmatches are in titles thast are never played. I would be wiling to bet BigCondor's DVD is one of these.

Regards

[Sir Didymus]

Not always. Imagine one cell used in two PGCs. One PGC can use the whole cell, and the other one only part of it. In this case, there is no unreferenced material...


Also, even in the simpler situation where the cell is just used once, it may be still possible - via the rewind button of the remote, to play through the initial cell content.

...Hem... I honestly admit the first who made this observation was mpucoder... :cool:

Anyway, the implication is that this initial cell content is not really a "gap", and it is most probably improper to qualify it as "unreferenced material"...

I was planning to do some tests with PgcEdit + the Phylips Verifier, [just to see what it say about...] but didn't until now...

Maybe in the next days, if nobody else is curious about...

Cheers,
SD

[r0lZ]

not sure what will happen if you go backwards from the remote, because of internal VOB pointers....etc) .This has been tested by someone and also by me on my Sony. Seems it works well. If you rewind past the entry point of the IFO, you can see the video that is not included in the IFO cell. But if you reach the first nav pack of the VOB cell, the playback jumps abruptly to the entry point defined in the IFO! That's strange, of course, but it's not a real problem. Using the Prev Chapter button jumps to the entry point of the IFO, including when you are playing the part of the video that is not in the IFO cell.

I suppose that fast forwarding past the end point works equally well, but I haven't tested that yet.

[BigCondor]

I ran thru VobBlanker, an unreferenced cell in that pgc was deleted and everything works well.
I look at that title with PgcEdit, there is a command line of jumping to the main title and it is never called!
So blutach's guess is right.

[r0lZ]

Unfortunately, it is not easy to determine that a PGC is never called. An unreferenced cell is not present at all in the IFOs, and can safely be removed from the VOBs, but the cells of the uncalled PGCs not! This is why I have added the function to remove automatically all uncalled PGCs in PgcEdit v8. This will make the cells unreferenced, so that you can remove them easily with VB or FixVTS.

[jsoto]

This has been tested by someone and also by me on my Sony. Seems it works well. If you rewind past the entry point of the IFO, you can see the video that is not included in the IFO cell. Yes, this is what I suspect, because the internal VOB pointers are still the ones of the whole cell. But I do not consider this to "work well", if the initial intention is to don't play part of a cell. So, my conclusion is that this situation cannot be considered as standard compliant. I'll wait SD tests with verifier... (although Phillips verifier complains about everything you can imagine and much more...)
jsoto

[blutach]

Different VOBU entry points are what we have been doing for years, haven't we? This used to be the standard way of bypassing FBI warnings (having the entry point = last VOBU end sector in cell) before post into pre became the method.

AFAIK, no player has ever complained. I'm not sure if the Verifier will - the manual might have some info.

Regards

[r0lZ]

Well, I remember I've used that VOBU method, and my Sony was really not happy (sometimes)!
But I was still a newbie at that time, and maybe I've used a VOBU address not pointing to a nav pack... :scared:

[Sir Didymus]

Hi blu!

Well, in case (as it should) the "compliancy" term is driven by the proper playback by standalones (and sw) players, then I agree that this trick is most probably OK. Hem - more or less - since it seems there are different behaviours regarding the way of handling the rewind through the new entry point: some players seems freely allowing to rewind, other seems not to allow this operation...

Anyway I did a quick test - it simply shows that the Verifier complains...:

1) VobBlanker - Extracted one VOB cell from a nice movie (Howl's Moving Castle...)... Beautiful title... :)
2) Demuxed video and (one) audio streams
3) MuxMan - reauthored a DVD (single title, single pgc, single cell)
4) PgcEdit session (needed to exclude possible errors introduced in the process so far... see steps below...)
5) Rebuilt all time maps and saved DVD
6) Run the Philips Verifier on this DVD, logging the errors
7) PgcEdit session, changed the cell entry point and saved the DVD
8) Run the Philips Verifier again on this DVD, logging the errors

Here the summary of the errors after step 6):

ERROR 4041 1
ERROR 4224 1
INFORMATION 4071 1
INFORMATION 4216 1
INFORMATION 4408 2
INFORMATION 5604 8


Here the summary of the errors after step 8):

ERROR 4041 1
ERROR 4224 1
ERROR 5827 1
INFORMATION 4071 1
INFORMATION 4216 1
INFORMATION 4408 2
INFORMATION 5604 8


The single difference, introduced by changing the entry point of the title, is:


VTS_01_1.VOB error log -->
>>> [DVD] ERROR 5827 (ref. DVD-3 4.3.5-1 (3)) :
The Start Address (0) of this Cell (C_IDN=1, VOB_IDN =1) does not correspond with the
Start Address of the first VOBU (25519) in Cell 1 in the C_PBIT table of PGCI 1
at byte 0 bit 0 of pack 4294967295 (PS stream byte 0).


Off topic: for the sake of curiosity (hem, due to the adopted procedure we don't know if the errors are generated by MuxMan, or are produced by PgcEdit), there are two reported complaints related to the absence of menues, both in the VMG and in the VTSM domain:


VIDEO_TS.IFO error log -->
>>> [DVD] ERROR 4041 (ref. DVD-3 4.1.1) :
VMGM_V_ATR: Some fields are non-zero when no VOBS exist (BP 256)
for VMGI at byte 256 bit 0

VTS_01_0.IFO error log -->
>>> [DVD] ERROR 4224 (ref. DVD-3 4.2.1) :
VTSM_V_ATR: Some fields are non-zero when no VOBS exist (BP 256)
for VTSI at byte 256 bit 0

[jsoto]

Anyway I did a quick test - it simply shows that the Verifier compalins...:
VTS_01_1.VOB error log -->
>>> [DVD] ERROR 5827 (ref. DVD-3 4.3.5-1 (3)) :
The Start Address (0) of this Cell (C_IDN=1, VOB_IDN =1) does not correspond with the
Start Address of the first VOBU (25519) in Cell 1 in the C_PBIT table of PGCI 1
at byte 0 bit 0 of pack 4294967295 (PS stream byte 0).
[/code] I was sure it will complain..

Off topic: for the sake of curiosity (hem, due to the adopted procedure we don't know if the errors are generated by MuxMan, or are produced by PgcEdit), there are two reported complaints related to the absence of menues, both in the VMG and in the VTSM domain:

VIDEO_TS.IFO error log -->
>>> [DVD] ERROR 4041 (ref. DVD-3 4.1.1) :
VMGM_V_ATR: Some fields are non-zero when no VOBS exist (BP 256)
for VMGI at byte 256 bit 0

VTS_01_0.IFO error log -->
>>> [DVD] ERROR 4224 (ref. DVD-3 4.2.1) :
VTSM_V_ATR: Some fields are non-zero when no VOBS exist (BP 256)
for VTSI at byte 256 bit 0

We already discussed about this... But IMHO, this is a not an error (just a non well done check of verifier). Video Attributes cannot be zero in a PAL DVD, only in NTSC ones.

jsoto

[Sir Didymus]

Oh my God,

I think I have to admit I loose this discussion - sigh...

All the best,
SD

[bigotti5]

But IMHO, this is a not an error (just a non well done check of verifier). Video Attributes cannot be zero in a PAL DVD, only in NTSC ones.

Not in this case
If no menu VOB is present byte 0x100 in VMGM_MAT (VTSI_MAT) has to be 0 in NTSC and PAL

0 represents "no VOB" and not the values of the individual bits
(you cant have 0 if VOB is present, even it is NTSC)

[jsoto]

Not in this case
If no menu VOB is present byte 0x100 in VMGM_MAT (VTSI_MAT) has to be 0 in NTSC and PAL
0 represents "no VOB" and not the values of the individual bits Seems you're right, but I'm convinced noone(settop/SWplayer) is going to look inside if there is no VOB...(as indicated in 0x00c0).
Just curious...what happens if there is a zero bytes menu VOB? Does the verifier complain?
(you cant have 0 if VOB is present, even it is NTSC) May be because 720x480 is not legit in MPEG-1?
jsoto

[bigotti5]

May be because 720x480 is not legit in MPEG-1?

Yes...
PanScan and Letterbox in 4:3 is not possible too

[jsoto]

PanScan and Letterbox in 4:3 is not possible tooOh yes!. I always forgot the right meaning of these bits. I always invert the meaning (1=allowed, which is wrong)
jsoto

[r0lZ]

I've just fixed that problem in PgcEdit, although I think also that all players accept non-zero video attributes with no VOBs. Why should they use (or even read) that info if they don't need it?

Anyway, I'm sure PgcEdit never changes the video attributes unless you explicitly do it via Domain Stream Attributes. Therefore, in Sir Didymus test (errors 4041 and 4224), PgcEdit is not the culprit.

Just curious...what happens if there is a zero bytes menu VOB? Does the verifier complain?I am interested to know the answer, too!

[bigotti5]

Just curious...what happens if there is a zero bytes menu VOB? Does the verifier complain?

How should I produce such a DVD?

[jsoto]

Use one DVD w/o menu.
Create a new text file (with explorer) and name it as VTS_01_0.VOB (or the menu you want)
Open IFOEdit and Get-VTS sectors .

jsoto

[bigotti5]

These would cause a lot of errors

Error No. 280 Error Name: N-VMG-2-041 Severity: Minor Error in: Video Manager Information(VMGI)
Error: Inconsistent data specifications in the title menu
Location:
Description: Error in VMGI_MAT: Video Manager Menu Cell Address Table(VMGM_C_ADT) does not exist while VMGM_VOBS exist
Specification Page Number: VI4-7

2 Error No. 283 Error Name: N-VMG-2-044 Severity: Minor Error in: Video Manager Information(VMGI)
Error: Inconsistent data specifications in the title menu
Location:
Description: Error in VMGI_MAT: Video Manager Menu Video Object Unit Address Map(VMGM_VOBU_ADMAP) does not exist while VMGM_VOBS exist
Specification Page Number: VI4-7

3 Error No. 286 Error Name: N-VMG-2-047 Severity: Minor Error in: Video Manager Information(VMGI)
Error: Inconsistent data specifications in the title menu
Location:
Description: Error in VMGI_MAT: VMGM_V_ATR : Video attribute of VMGM_VOBS is NULL while VMGM_VOBS exist
Specification Page Number: VI4-7

4 Error No. 297 Error Name: N-VMG-2-058 Severity: Minor Error in: Video Manager Information(VMGI)
Error: Error in video manager sub picture attribute specifications
Location:
Description: VMGI_MAT: VMGM_SPST_N : Number of Sub-picture streams is 0 while VMGM_VOBS exist.
Specification Page Number: VI4-11


Error 3 and 4 can be corrected by editing the IFO

Edit:

If there is no PGC in VMGM you get also this error
Error No. 270 Error Name: N-VMG-2-031 Severity: Minor Error in: Video Manager Information(VMGI)
Error: Inconsistent data specifications in the title menu
Location:
Description: Error in VMGI_MAT: Video Manager Menu PGCI Unit Table does not exist while VMGM_VOBS exist
Specification Page Number: VI4-6

[r0lZ]

Thanks, bigotti5.

Again, commercial DVDs with empty VOBs and no references in the IFOs are common (although I haven't seen one of them recently.)
Nero complains, and PgcEdit offers to remove such VOBs (and the references if they are present.)

[jsoto]

Again, commercial DVDs with empty VOBs and no references in the IFOs are common (although I haven't seen one of them recently.) Yes, they are very common
Nero complains, and PgcEdit offers to remove such VOBs (and the references if they are present.)which references are you talking about?. AFAIK, a zero bytes menu cannot have a cells table nor a VOBU table... (verifier will complain too)
jsoto

[blutach]

Very interesting tests SD and bigotti5.

This thread has been extremely educational.

Regards

[r0lZ]

which references are you talking about?. AFAIK, a zero bytes menu cannot have a cells table nor a VOBU table... (verifier will complain too)VTSM_C_ADT, VTSM_VOBU_ADMAP and the stream attributes in VTSI_MAT. I remove them anyway, just in case, but I must admit that I don't know if those table are defined, and if it's useful. It's easy to do anyway. :)

[jsoto]

.. the stream attributes in VTSI_MAT. Mmm. IIRC I'm not clearing these values when VobBlanker deletes the zero bytes menus...I'll check it and will do it if it is not already done.

jsoto

[bigotti5]

commercial DVDs with empty VOBs and no references in the IFOs are common

And are there VTSM_C_ADT (VMGM_C_ADT) and VTSM_VOBU_ADMAP (VMGM_VOBU_ADMAP) tables and if what entries do they have?

[r0lZ]

Well, I haven't verified that, and I don't have such a DVD on my hard disc currently. I suppose that if the tables are present, they have empty entries.
Anyway, as I said, PgcEdit removes the tables when the VOB is deleted.

[jsoto]

I've looked into some of my originals (my backups do not have zero bytes menus), but I didn't found one.. Next time I see one I'll look into the IFO for the details

VobBlanker also deletes these tables when removes the menu file.

jsoto

[mpucoder]

Wow, I missed a lot in the last day. About the 4041 and 4224 errors, I consider them to be less severe than the 5607 and 5777 errors that occur when the byte is zero on a PAL DVD. Error 5607 is not documented in the manual, here is the text of the error:
>>> [DVD] ERROR 5607 (ref. DVD-3 Annex N, Table N-2) :
VTSI: The VTS_ATRT VTS_V_ATR specifies a TV system 1 (PAL) different
from the TV system 0 (NTSC) specified by the VMGI_MAT VMGM_V_ATR.
for VTSI at byte 512 bit 2 and to refresh memories about the 5777 error
>>> [DVD] ERROR 5777 (ref. DVD-3 4.3.2-1 (2)) :
PGC_GI.PGC_PB_TM: The tc_flag (1 '25 frames/s') does not correspond with the TV_system (0 'NTSC'),
this flag must be 3 ('30 frames/s non-drop frame')
for PGCI at byte 4119 bit 0
VTSI at byte 4119 bit 0

note that the 5607 occurs on a check of the VTS_V_ATR table which is a copy of each VTS's attribute area. Error 5777 occurs only if there are dummy PGCs as they have a duration of 0 (no video), but still indicate a tv_system

In short, there is no way to satisfy the Philips verifier for a PAL DVD with no menu video

[bigotti5]

Sorry for off topic

@mpucoder

Cant reach your site for days, is it me or is your site down?

[mpucoder]

Site is down due to financial problems. I expect to have the site back up by Dec 15. At that time MuxMan 0.18, the forerunner of 1.0, will be available for sale.

[bigotti5]

Thx for info

--

Error 5607 in case of PAL without menu VOB is still a bug in Philips verifier

[r0lZ]

Sad news, mpucoder! :( I hope you will soon sell tons of Muxman licenses!

[Sir Didymus]

...and to refresh memories about the 5777 error...

...In short, there is no way to satisfy the Philips verifier for a PAL DVD with no menu video

Well, really my memory needed a refresh...
I now remind the point...

And rechecked it (completely confirming - even though it was not necessary - what you say). By manually changing to 0 the above addresses $100 in the ifos, lead to the errors you described...

Anyway, don't you think, at the end, that these addresses in the ifos should be zeros in case no menu is present ?

It's clear that 5607 and 5777 are serious errors, but it's also very clear that the Philips is reporting silly things in this situation...

Edit. Mhhh. Thinking further on the matter, after all I am not completely convinced by my arguments. May I retract the suggestion just given ? - And sorry for the little meaningful post; please take it just as a loud voice reasoning...

[jsoto]

Uh!.
I've changed VobBlanker (in beta10) to clear the videoattributes completely (zero) if no menu trusting Phillips verifier.... Previous versions were clearing everything except the PAL and MPEG-2 coding flags (which obviously was not enough).

jsoto

[Sir Didymus]

Hi Jsoto!

Well, just to claryfy my point of view, (but please, take it just as an opinion...), I think too that the proper value to set should be 0 in case no menues are present; however, this opinion is based just on the common sense, and it is not strongly convincing, since the tools to verify the matter are (most probably wrongly) reporting even worse errors in case this address is cleared.

Since the DVD specs are not available to me, I can not say much more...

I would be very curious to know what OTHER format verification tools are reporting on the matter...

[jsoto]

I think too that the proper value to set should be 0 in case no menues are presentMy common sense disagree...IMHO, the standard PAL/NTSC should be correctly configured, even if no menus are present. So, if it is not zero, other values (codification , aspect ratio, etc) should be also correctly configured.

In any case, all of this is a minor thing. Noone (except us & verifiers) will look inside if no menus are present.

jsoto

[r0lZ]

Since I have changed that in PgcEdit too, I am also very interested to know the answer at this difficult question!
Someone has "the other verifier"?

[bigotti5]

Someone has "the other verifier"?

Did my tests on Interra, not Philips

[r0lZ]

So, the Interra verifier confirms that the video attribs must be 0 when the menu VOB file is not present? Right?

[bigotti5]

So, the Interra verifier confirms that the video attribs must be 0 when the menu VOB file is not present? Right?
Yes - error messages in post #40 are from interra

Here the error messages in case of PAL defined in VMGM_MAT and VTSI_MAT and no VOB exists

1 Error No. 383 Error Name: N-VMG-2-144 Severity: Minor Error in: Video Manager Information(VMGI)
Error: Error in VMGI_MAT
Location:
Description: Error in VMGI_MAT:VMGM_V_ATR: Video attribute fields are defined for non existing VMGM_VOBs.
Specification Page Number: VI4-7

2 Error No. 491 Error Name: N-VTS-2-052 Severity: Minor Error in: Video Title Set Information(VTSI)
Error: Inconsistent data specifications in a video title set menu specifications
Location:
Description: Error in VTSI_MAT: VTSM_V_ATR: Video attributes exist for non existent VTSM_VOBS
Specification Page Number: VI4-42

[Sir Didymus]

I like this place...

Some times you find nice answers even to very triky questions...

Thanks bigotti5 !
SD

:)

Edit: are you positive, also, no errors are reported in case addresses $100 in the ifos are 0, right ?
Cheers...

[Sir Didymus]

My common sense disagree...IMHO, the standard PAL/NTSC should be correctly configured, even if no menus are present. So, if it is not zero, other values (codification , aspect ratio, etc) should be also correctly configured.

Well agreed that's definitely a minor thing - we are spending really too much sugar ( --> brain energy ...) for that...

Anyway, what I wanted to say is:
In case of menu is present, the whole byte at $100 in the corresponding ifo file can not assume the value of 0, right ?

So, this seems to me one of the few parts where the specs behaves in "compliance" with the commons sense --> eg. using the value 0 to codify the fact that no menu is present...

Am I babbling ? :confused:

[bigotti5]

are you positive, also, no errors are reported in case addresses $100 in the ifos are 0, right ?

No errors if $100 in the ifos are 0

[r0lZ]

OK, it's what I have programmed in PgcEdit, and I think I'll not modify that again.

Thanks for your researches, guys!