tartak Posted February 24, 2008 Posted February 24, 2008 (edited) 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. Edited February 24, 2008 by tartak
LIGHTNING UK! Posted February 24, 2008 Posted February 24, 2008 So it just needs 'Entry VOBU Sector' and 'Last VOBU End' info added (complete with a conversion to MB) for Cell 7 of VTS_01, PGC 1? (Obviously that last bit changes but I use it as an example)
tartak Posted February 24, 2008 Author Posted February 24, 2008 (edited) 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? Edited February 24, 2008 by tartak
blutach Posted February 24, 2008 Posted February 24, 2008 Most people would use the freeware VobBlanker which uses DVD2AVI and works in sectors. If you need VOBUs, you can calculate them from the VOBU_ADMAP table. In the above case, 253163 is the entry sector of the cell and I am splitting 32918 in, so the "abolute sector" is 286081. People need to know this info (ie where in cel # a split might be OK). Regards
tartak Posted February 25, 2008 Author Posted February 25, 2008 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.
LIGHTNING UK! Posted February 25, 2008 Posted February 25, 2008 If I told you that I don't have a 'corridor' calculated at this point, would I be right in thinking there's nothing I can add to make any difference? Like the relative Cell LBA's etc are useless as you pick the cell directly?
tartak Posted February 25, 2008 Author Posted February 25, 2008 (edited) 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? Edited February 25, 2008 by tartak
LIGHTNING UK! Posted February 25, 2008 Posted February 25, 2008 PgcEdit and ImgBurn are performing calculations at two different times. I'm doing it mid build of the filesystem, r0lZ is doing it when that's all finished. His is a little easier to work with. Actually, I think that's where I'm going wrong. I shouldn't be trying to figure out which one needs splitting as I go along, I should be doing it at the end if everything else fails. I'll rewrite that bit quickly.
tartak Posted February 25, 2008 Author Posted February 25, 2008 (edited) I'll rewrite that bit quickly. 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). Edited February 25, 2008 by tartak
LIGHTNING UK! Posted February 25, 2008 Posted February 25, 2008 I had to make up some odd disc sizes to force such an error, but hopefully you get the idea! Is that going to be ok?
tartak Posted February 25, 2008 Author Posted February 25, 2008 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?
LIGHTNING UK! Posted February 25, 2008 Posted February 25, 2008 1. There's as much of a corridor in my text as there is in PgcEdits! I actually took it one step further and gave you the relative sector in the Cell itself But ok, I guess I could add the other end too 2. As many people have found out, the start of a cell being perfectly aligned with the physical LB is not vital in all players. Lots of players don't care too much about the layer break and I don't like to force anything upon anyone. People might also have legit reasons for trying stuff without forcing them to split cells and all that other rubbish just to make the program burn!
tartak Posted February 26, 2008 Author Posted February 26, 2008 (edited) 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. Edited February 26, 2008 by tartak
blutach Posted February 26, 2008 Posted February 26, 2008 You can of course use the preview to find the right place and also make it look nice. Or use seamless and just don't worry. But it also can't hurt to add a decimal point. As for proceeding anyway, yes those players are very much outa spec but so many "kiss" players work OK. I might suggest adding an "Are you really sure - DL media is real expensive so don't blame me if it turn out shithouse" dialogue to those who click "Yes". Regards
LIGHTNING UK! Posted February 26, 2008 Posted February 26, 2008 1. I was hoping that wouldn't be necessary! Relative is still relative, it's just to different things. I'll just do away with the 'relative' word in the last line. The text is too long if I start having to explain everything! 2. I've done it to 2 decimal places now. So now pick between these two...
tartak Posted February 26, 2008 Author Posted February 26, 2008 (edited) 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. Edited February 26, 2008 by tartak
tartak Posted April 2, 2008 Author Posted April 2, 2008 (edited) 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)? Edited April 2, 2008 by tartak
blutach Posted April 2, 2008 Posted April 2, 2008 Simply a matter of padding - nothing to worry about. Regards
tartak Posted April 2, 2008 Author Posted April 2, 2008 I don't worry, I'm just curious. If it's padding, how come the relative numbers are a bit different too?
blutach Posted April 2, 2008 Posted April 2, 2008 I see no difference in the relative number - it is taken for the C_ADT table and is 1918647. Regards
tartak Posted April 3, 2008 Author Posted April 3, 2008 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.
LIGHTNING UK! Posted April 3, 2008 Posted April 3, 2008 It's magic! Or maybe it's just down to a different file system implementation?
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now