tartak

You did, I remember. It's just I thought you actually have control over when this command (SEND DISC STRUCTURE with Format 20h) gets sent and executed. My drive made the LB non-changeable before any user data was written..

LUK! Thanks for the pointer, I do fancy low-level stuff. Looked it up in MMC-5 r.4 (t10 wants money for it, but it's free on t11 site). The write-up for SEND DISC STRUCTURE with Format 20h does not really say where the info is written, but READ DISC STRUCTURE 20h (p. 445) clearly says that L0 Data Area Capacity is written into Control Data Zone in Lead-in. For one, you were wrong, my god of dvd burning is only human! BTW, the overview on p. 101 says that this user selected L0 capacity is written when the session is closed: Does not this contradict to ImgBurn setting LB before it even starts writing the session? blutach, I have a great deal of deficiencies, but I would not even imagine using ECC/VOBU method. I was simply testing in some dark corners, in search for an answer to some other question (about the real reasons for "end of the world" situation).

Well, I did click on the big button, yeah So, I see your point. It's just that ImgBurn is so intuitive and consistent, and I got spoiled. In the other situations, it starts doing something to the disk only immediately after a click on the Big Button, or after a nice summary dialog, where you'd have OK and Cancel buttons and you need to click OK. That's the only reason I did not expect a physical change in the disk after a click on something other than the Big Write Button or OK button. Seems a bit inconsistent to me, but it could be just me. I'm really curious, where the LB modification resides on the disk? My blank disk is physically changed, I ejected it and put back to verify. You said it's not in leadin zones; so it means one can modify the data zone and the disk is still empty? Oh, and what does that "Revert to VOBU/ECC search" do? I could not find any mention in the guides. ADDED: I've found the answer to the last question in this post

Well, as I said, it may be by design. All I'm saying - the Build to device mode is inconsistent in this regard to Write mode. I don't know where and what ImgBurn wrote, but it has. And without a warning, after clicking on a button that the user can't anticipate would initiate any writing to the disk. I sacrificed one more disk and reproduced the "situation" (well, the disk is still empty, I can use it, just not for DVD-Video). Here is the info before I did anything: TSSTcorp CDDVDW SH-S203N SB01 (ATA) Current Profile: DVD+R DL Disc Information: Status: Empty Erasable: No Free Sectors: 4,173,824 Free Space: 8,547,991,552 bytes Free Time: 927:32:74 (MM:SS:FF) Supported Write Speeds: 2.4x, 4x DVD

I'm not sure it really qualifies as a bug, but it was sure very unexpected and disconcerting to me when I've run into this problem. I got used to writing DVD-Video from VIDEO_TS. In this mode, before ImgBurn actually starts writing anything, it gives a fair warning, with all the information (label, options and such). This time however, while testing some things, I decided to write from a dvd-9 iso image (no mds). ImgBurn gave me the expected dialog for LB selection. At this point I noticed a button that I had not seen in the similar dialog in the file mode - "Revert to VOBU/ECC search". Intrigued, I clicked on the button. All of a sudden, ImgBurn spins the disk up, and then sits there for a while, seemingly doing nothing. I'm getting concerned and click on Abort. Everything looks fine, the disk is still shown as Empty and available to burn. But there is no position for LB anymore. The reason is obvious - the capacity of the disk is slightly diminished relative to a real blank, and it shows "Changeable: No". So, ImgBurn actually has permanently set the LB (I assume it's in the lead-in, am I right?), without a fair warning, after clicking on a button that does not say anything about burning. PS. The disk was Verbatim +R DL MKM-001

blutach, You're right - and I said the same in my 1st post. The second time around, I was looking at the relative numbers for LB corridor. Yeah, it makes sense now, they'd be different given a different padding. I'm still curious. I remember r0lZ mentioned that the padding algorithm in ImgBurn v. 2 was the same as in PgcEdit (when explaining that there is no need anymore to use PgcEdit to burn DVD-9). Yet, somehow, the LB corridor in ImgBurn is 4 sectors wider - by 2 sectors at each end.

I don't worry, I'm just curious. If it's padding, how come the relative numbers are a bit different too?

LUK! Thanks for the new version and the new "End of the world" dialog! To follow up: it works fine for me, but, while replacing screenshots in my instructions, I noticed a small discrepancy between PgcEdit and ImgBurn numbers. Compared to PgcEdit, the absolute LBA of the start of the VTS is less by 2 in ImgBurn, while the relative start of the cell is the same. The relative numbers for the LB corridor are a bit different too: Does not really matter for the cell cutting procedure, just curious... Could it be due to AUDIO_TS (perhaps dropped from the calculation)?

I vote for the second. Maybe "Counting from the start of Cell4, ...", just to avoid repeating 'relative' so many times? Anyway, English is not my native tongue, I may not feel some subtleties Thanks, master LUK! PS. I do like blutach's wording. 'Want to continue? (Not recommended)' sounds kinda ambivalent. But then again, I grew up in a very paternalistic society, I might not appreciate the true freedom of choice.

You're right about PgcEdit - you've already had more info in the first variant. But we want ImgBurn to be perfect, as much as humanly possible! And yes, I gather you have a point about the newer players. Sorry for my fussing about the details: 1. In the last to next sentence, you use 'relative' with a different meaning than in the sentence just before it. This time, it's relative to the start of the cell, while it was relative to the start of the title before. Kind of confusing. Perhaps you just say so: "relative to the start of the cell", or "from the beginning of the cell"? 2. Also, you seem to truncate the MBs. It would be safer to round the first (start of the corridor) up, and the second (end of the corridor) down. Or just give them with 2 decimal places, as shown in Remake.

Splendid! Just two things: 1) The next to last sentence, you may want to make it like "So, try splitting that cell between sectors 15233 (29.76 MB) and 106611 (208.22 MB) from the start of the cell." I'd prefer to know the whole corridor. Given the corridor, I still hunt for a scene change, or at least some static moment. 2) Why let continue at all? I mean, someone who realizes what's going on would never continue. But, a novice, given an intimidating dialog like this, would be tempted to try his luck, wouldn't he?

Wow, it's really amazing when one can talk directly to the author and get a response like this. Thank you very much for your great ImgBurn and for the one before it The topic with my translation of your instructions, on torrents.ru, is 19 pages full of posts at this moment - by far the most popular topic on the whole site. Every now and then people ask what makes ImgBurn so much better than Nero. The 2nd out of 3 top reasons I give is: you can talk to the author, it's not an anonymous team (the other two - it handles DVD-Video right, and it's very light and stable).

In the tools most people use (PgcEdit, Remake Pro, VobBlanker), the cell is picked directly. If... I mean, obviously, for any cell boundary, you can calculate whether it can be used for LB - that's the stars in LB dialog. If there is no suitable boundary, you can say which cell should be split - that's the "End of the world" dialog. Perhaps you do this by checking all cell boundaries. But even then, if you really don't have a direct 'corridor' calculation, you definitely have something very close, a reverse calculation - for any LBA, you can say if it gets into that corridor. Also, PgcEdit source is available, perhaps you could lift the calculation from there or ask r0lZ?

I could easily do without VOBUs in Remake, having MBs is enough. So having both sectors and MBs would cover all bases: VobBlanker and Remake Pro, without any need for additional programs.

To find the spot in Remake's preview window, you would need to know the position of the start and end of the LB corridor, relative to the cell's 'Entry VOBU Sector'. So, in this example, 2037745 (from the first screen) - 1918665 = 119080 and 2049729 - 1918665 = 131064. Complete this with a conversion to MB (* 2 / 1024), and we can easily pick a spot in Remake while previewing the scene: LB should be between 232.58 and 255.99 MB from the beginning of Cell 7. The discrete slider in Remake goes by VOBU, so ideally we would also want to know the corridor in VOBU numbers. But that be too much to ask I guess - the VOBU time varies a bit, right?

On a rare occasion, there is no cell boundary that can be used for the layer break. In v. 2.4, ImgBurn gives this "End of the World" message: Two suggestions: 1) Have just one option at this point - Cancel. I'd think it's not a good idea to let the user proceed at this point. In a similar situation, RecordNow just refuses to continue. Everyone trusts that ImgBurn would not do something silly, so why let the user do something silly now? 2) Adding a new cell at the right spot, right in the preview window, is very easy with DVD Remake Pro. All one needs to know is the location of the possible corridor for LB - in sectors, relative to the start of an existing cell. PgcEdit gives a similar dialog with the needed numbers: One just needs to subtract the starting sector of the cell: and translate sectors into MB, 1 sector = 2 KB (Remake shows megabytes rather than sectors in its preview) So, it would make it a lot easier if ImgBurn could give not just the cell, but also the location of the LB corridor inside this cell - in sectors and megabytes, relative to the start of the cell.

I'm very happy to report that the same disk made it through Philips UDF Verifier with no problems. Well, it did detect the same "errors" with ImgBurn identifiers as DVD Verifier, but it's found both anchor points: Reading Volume Information 256 read block AVDP at 256 (MVDS: 32, RVDS: 48) First Tag Serial Number: 0 Note: Tag Serial Number 0, no disaster recovery support, - ECMA 3/7.2.5, 4/7.2.5, UDF 2.3.1.1. - ==> Message printed once, ignored from now. 3454111 read block No AVDP at N-256 3454367 read block AVDP at N (MVDS: 32, RVDS: 48) Number of AVDPs: 2, AVDPs at 256, N I got the most recent version of udf verifier (1.5 r6, more recent than at hitech-projects.com) from Philips, UDF Verifier Software, one simply needs to register there. They do say in some of the release notes that they improved AVDP detection. I'm shocked that Philips got it right in their free udf verifier and screwed up in dvd-video verifier, which is far from being free. For a second, I thought it might have something to do with DL media, so I got a dvd-5 through dvd-video verifier - same result, only one AVDP found. Is there any more recent software than philips dvd-video verifier, that could still check the whole thing? Something more or less reasonable, of course, not the $10K+ Eclipse and MEI stuff the replicators use...

Well, I did not write an ISO, I wrote DVD Video files directly to a DVD-9 in the Build mode. It should not make any difference, though, right? Could it be because of double-layer media? And, of course, I don't have 2.4.0, I wish I did It's not that I'm unhappy with 2.3.2 in any way - it's just they ask me questions, a lot. Just in case - I used Verbatim MKM and BenQ-1640. Today I repeated the test, different DVD, different computer, burner - Samsung SH-S203N, media +R DL Verbatim MKM. Exactly same errors. Here is the log from Verifier (1.5.0/4.6.0, released April 11, 2003) - I skipped all mpeg and DVD verification: ******************************************************************** * * DVD stream input type = Disc(image) * * Decoding skipped for MPEG levels : * TRS stream * PES stream * Video Sequence * Macroblock * Audio Sequence * Audio multi-channel data * Dolby AC-3 audio * Padding Stream * Private data * DVD levels : * * Verification disabled for MPEG levels : * PSI-tables * Pack header * System header * DVD levels : * ******************************************************************** >>> [iSO9660] ERROR 5518 (ref. ISO 8.4.26.1) : Date Time format has an incorrect Year attribute: The value must be in the range 1..9999, but the actual value is 0000 at sector/block 16, byte 847 bit 0 >>> [iSO9660] ERROR 5518 (ref. ISO 8.4.26.1) : Date Time format has an incorrect Month attribute: The value must be in the range 1..12, but the actual value is 00 at sector/block 16, byte 851 bit 0 >>> [iSO9660] ERROR 5518 (ref. ISO 8.4.26.1) : Date Time format has an incorrect Day attribute: The value must be in the range 1..31, but the actual value is 00 at sector/block 16, byte 853 bit 0 [skipped rest of ERRORs 5518] >>> [uDF] ERROR 5213 (ref. UDF 2) : #anchor points found is: 1, two anchor points were expected at sector/block 256, byte 16 bit 0 >>> [uDF] ERROR 5064 (ref. ECMA 1/7.4, UDF 2.1.5) : Regid identifier is '*ImgBurnInfo'; It must be as specified in UDF Appendix 6.2. at sector/block 33, byte 21 bit 0 >>> [uDF] ERROR 5231 (ref. UDF 2.2.4, 2.2.7.2.2) : LogicalVolumeIdentifier of IUVD (UGLY_SWANS) does not equal (null) (LVD) at sector/block 33, byte 52 bit 0 >>> [uDF] ERROR 5232 (ref. UDF 2.2.7.2.2) : No IUVD has Implementation Id of *UDF LV Info at sector/block 33, byte 52 bit 0 >>> [uDF] ERROR 5064 (ref. ECMA 1/7.4, UDF 2.1.5) : Regid identifier is '*ImgBurnInfo'; It must be *UDF LV Info. at sector/block 33, byte 20 bit 0 [skipped rest of ERRORs 5064, 5231, 5232] >>> [uDF] ERROR 5064 (ref. ECMA 1/7.4, UDF 2.1.5) : Regid identifier is '*ImgBurnInfo'; It must be *UDF LV Info. at sector/block 49, byte 20 bit 0 >>> [uDF] ERROR 5355 (ref. UDF 3.3.3.4) : Unique Id 0x0000000000000002 is not 0 for root directory or between 1 and 15 at sector/block 264, byte 160 bit 0 [skipped rest of ERRORs 5355] >>> [iSO9660] ERROR 5530 (ref. DVD A.14) : The System Use field must contain the Copyright Management Information, and no more information is allowed at sector/block 259, byte 35 bit 0 [skipped rest of ERRORs 5530] ************************************************************ * * ERROR SUMMARY : * * No Informations * No Recommendation violations * No Oddities * No Warnings * No Syntax errors * 74 Errors * No System errors * ************************************************************

First of, I'd like to thank LUK! for his outstanding program. Have used it to burn more than 1000 DVD-Video, about half - DVD-9, all without a glitch! To spread the word, I've translated LUK!'s guide into Russian, added some additional info found in this forum, and posted the whole thing on some of the biggest russian forums, about half a year ago. It's been spreading around ru-net ever since. Well, I had no choice but become a resident "expert" and now they hold me responsible for any problem - as long as ImgBurn is somehow involved. After some discussions about what makes a DVD conforming, I got an idea to run a few ImgBurn'ed disks through Philips DVD-Video Verifier. The check did not catch any problems I would consider of much importance. Yet one thing was curious, I thought I'd better ask here. Here is from the log: >>> [UDF] ERROR 5213 (ref. UDF 2) : #anchor points found is: 1, two anchor points were expected at sector/block 256, byte 16 bit 0 And the explanation in the manual: ============================ >>> [DVD] ERROR 5213 (ref. DVD-2 2.3, UDF 2 and ECMA 3/8.4.2.1) : ERR_ANCHOR_POINTS_NOT_TWO According to [uDF] 2, the number of recorded AVDP must be exactly two. They must be placed at two of the following three places: logical sector number 256, N-256, or N, where N is the last addressable sector of a volume. According to [DVD] 2.3, the AVDP must be recorded at 256 and N, where N is again the last logical sector number. ============================ As I understand, the disk is no longer usable if there is a defect at the anchor point, so it is duplicated for protection. ImgBurn seems to produce only one anchor point - is it a problem? What's the deal with these anchors, how do they work?