Jump to content

fordman

Members
  • Posts

    184
  • Joined

  • Last visited

Everything posted by fordman

  1. Ooops, yes, that is what I meant to say, I meant to say would NOT trigger any such checks. I modified my post to reflect that. Otherwise it made no sense... Thanks for the verification, LUK.
  2. Thanks blutach, That's what it seemed would happen, but I wanted to be sure. The only reason is that I once had an .ISO that had an old LB flag that was no longer valid, but a potential position that wasn't flagged. I believe it was a PTP image that just happened to have a valid cell where an OTP disc could switch to the second layer. LUK suggested imgburn (1.3.0.0 at the time) should have offered to delete the old flag when it inserted the new, valid flag. I ended up with two flags in the burned disc, one at the new valid point, and the old one. LUK modified the code to do better checking... Anyway, this is a different circumstance, where there is a new, valid flag, so I figured it would NOT [edit] trigger any such checks. Regards, Ford Man
  3. Hello, I re-mastered a DVD to ISO (I reverted to PGCEdit because I wanted 32K padding), and after deleting the source VIDEO_TS files on my hard drive, I discovered I had let the old LB flag in when I changed the layer break position to the previous cell (wanted it to coincide with a scene change). So, I have an ISO file with two LB flags - one at VOB/Cell ID of 1/31 (the new correct one), and the old one at VOB/Cell ID 2/1 (the previous one that is no longer needed). Yes, I ensured that the cells had the same mux rate... So, if I burn this ISO as it currently is, will Imgburn offer to delete the old one? When I use the view layerbreak tool, it shows that the new one I set is the only valid one, so I'm guessing that it will not offer to delete the old one. Is this the case? Should I therefore extract the files and remaster it? Thanks, Ford Man
  4. Great! - thanks. This will make it much easier to re-author a DVD and make it appear like the original...
  5. Not sure if this is a bug, or just the way UDF recording is. I have built several images with ImgBurn's build mode, and was pleased by the date/time stamping functions, to include even stamping the parent and current directory entries (as viewed from a command prompt). When setting the custom stamp, I set both the "Creation" fields in the "Volume Dates" area, and also the "Use Custom Date & Time" fields in the "Folder/File Dates" area. While I've found that images built in this manner correctly set the folder file dates and times, I find that when I examine the media with DVDInfo Pro, there is a "UDF Recording Date/Time" field that shows the actual date and time I recorded the image, instead of the custom creation time I set. Am I missing something - should the "UDF Recording Date/Time" time be the same as the Volume "Creation" date? If not, is there a way to set the "UDF Recording Date/Time" time, or is this out of any recording program's control? Also, if not, where is the custom creation date stored? I think I found both dates in sector 16 of ISOBuster's sector viewer. If it is possible to change the creation date, is it also possible to change the "UDF Recording Date/Time" time which is stored along side the volume creation time? When I examine backups of pressed DVDs, it does seem that the "UDF Recording Date/Time" is set by the authoring program, and not by the actual time the image was burned. So, is it possible for ImgBurn to write the volume creation time into this field (if specified) instead of the current date and time?
  6. Actually, I thought RecordNow Deluxe 7.3+ was the way to go to burn dual layer DVDs directly from VIDEO_TS files, but I then ran into an instance where it failed. In the instance where it failed, I had over 3 hours of video in a title, and found the RecordNow did NOT insert the layer break flag as expected! Upon further examination, I discovered the reason. The cell (identical VOB/Cell ID) where the layer break flag should have been inserted was also used in another title, and RecordNow chose to flag the cell ONLY in that title! The end result was that the DVD would insert the necessary wait when playing that secondary title, but NOT when playing the main title - essentially the main title played as though it had a seamless layer break! I asked on the ImgBurn support forum whether the PGCEDIT/mkisofs combination would recognize and flag all instances of that vob/cell, and the answer was that it would, and I've since verified that in practice. I have not yet verified that the ImgBurn build mode will do the same as PGCEDIT/mkisofs in this instance, but if LUK has followed the logic of PGCEdit, then I assume it does. So, you can tell those people that ImgBurn is MORE COMPATIBLE than RecordNow! After that failure, I began using PGCEdit exclusively to make my dual layer images, even though it required an extra step compared to RecordNow, and I've since switched to ImgBurn's build mode, though I do avoid using it if the image I'm writing needs the 32K padding....
  7. There are two issues that were covered in this thread: 1. My observation that ImgBurn does not strip the padding from IFO/BUP files and update the end sector in the IFO/BUP in the manner that PGCEdit/IFOEdit do. 2. There is a confirmed bug with updates to the IFO/BUP when ImgBurn requires padding to conform to the 32K minimum gap between files. So, as long as you can observe that your files won't require 32K padding, or you have the option turned off regardless, then number 2 should not be an issue for you. I believe LUK is releasing a fix for this on the weekend. I've successfully burned two ImgBurn created dual layer images, and both were seen by AnyDVD as valid video DVDs, but neither one needed 32K padding (though I do have the option on). On the 3rd image, I did some experimentation and observed the behavior in number 1. At first it was assumed (by me and then LUK) that this was related to the 32K problem. However, on re-exmination, that image didn't require 32K padding either. Instead, I was observing that PGCEdit and IFOEdit recognized that the end sector didn't match the IFO size and fixed it. Meanwhile ImgBurn ignores that mismatch and adds the IFO/BUP to the image untouched. Running this through PGCEdit first to fix the mismatch, and then making an ImgBurn image ended up doing the trick. Since I'd like to use Imgburn primarily for the nice time/date stamping of files in the created image, I'll continue processing the files in PGCEdit (open and then save) and then create the image with ImgBurn... In conclusion, you will not experience 2 if you have the 32K option turned off, but you may experience the behavior described in number 1. This thread went on to debate whether that is a problem or not. However, since both PGCEdit and IFOEdit found that the existing end sector specified in the IFO did not match the IFO size, but ImgBurn retained both the specified end sector and the IFO size, there seems to be an issue, though it may be the same issue with updating the end sector that causes the 32K bug.
  8. It's not your risk fordman, and I for one am not prepared to discuss IFO manipulation on this forum (and I don't think you are suggesting we do that either). Most people know where I hang out (doom9 and digital digest) and you can talk freely with me and other more knowledgable people there. I look forward to it. Regards[/color] Sounds good. The risk I was referring to is the one you brought up, not any risk to me. This thread was merely pointing out that it would be nice if ImgBurn's build mode could fix the "damage" done to IFOs when content is stripped from a DVD (for instance one I author), like PGCEdit and IFOEdit currently do. I'm definitely not advocating any other purpose. It appears that r0lZ has pointed out an instance where the padding may not always be the best approach for the .BUP files, so perhaps stripping the padding is truly the best... I'll look forward to further discussions at the other forums! Thanks Ford Man
  9. Understood. However, I think we were talking about IFOs affected by stripped content. Surely that is relavent to homemade DVDs also? No risk I would think.
  10. blutach - you are indeed correct. I went and looked at both the 16K (pre-PGCEdit/IFOEdit or Post IMGBurn 2) and compared it to the 12K VIDEO_TS.IFO (post-PGCEdit/IFOEdit), and there are indeed all zeros at the end of the files. For the 16K one, there are approximately 5K of zeros at the end, and for the 12K one, there are approximately 1K of zeros at the end. So the PGCEdit and IFOEdit tools are shortening the IFOs by deleting the unneeded zeros to the closest sector that does not contain all zeros, it appears. So, it appears that LUK is correct that he could leave the files padded at 16K, and the PGCEdit/IFOEdit method is equally as valid, as long as the ending sector address is updated in the IFO. However, in light of what r0lZ wrote in this thread about using the end-of-table pointer to delete the null bytes while working around protection schemes, I wonder if the ImgBurn method of leaving the padding will work in all instances? Perhapse the PGCEdit approach of shortening the IFO is the best if the DVD files happened to be from a formerly protected DVD? Thanks for prompting me to look!
  11. I suppose it's the IF that I'm not sure about. Is it really empty space, or is it the remnants of VTS info from titles that no longer exist? If it's the latter, it seems that it should be deleted to be consistent with the actual VOB content. The discussions I've read seem to indicate that's what PGCEdit and IFOEdit are doing. From a DVD structure standpoint, I'm sure you're probably correct that having that phantom info in there isn't a problem as long as it's never referenced. I've tried comparing two such IFOs side by side in IFOEdit (for ex, a 16K original, and a 12K processed one) and couldn't find where the 4K went. It seems like the same "volume" of information was in each file. That's why it would be handy to be able to dump all that to a text file or otherwise do a side by side comparison. The PGCEdit author seems to frequent your forums pretty often. Perhaps he could shed some light on his methodology?
  12. Hopefully not the same things that plagued your previous utility. I would imagine you could approach it like CloneDVD does, where it only works on unencrypted DVDs. If a user wants to do something more than that, then there are those helper apps that take care of that issue. Also, making CD images should of course be for straight data type CDs, not protected games. "approach it like CloneDVD does" - you mean like offer another product for sale that does the decrypting part? Well, LUK would not. My point is that there are already enough utilities that do that out there.
  13. Hopefully not the same things that plagued your previous utility. I would imagine you could approach it like CloneDVD does, where it only works on unencrypted DVDs. If a user wants to do something more than that, then there are those helper apps that take care of that issue. Also, making CD images should of course be for straight data type CDs, not protected games.
  14. There's at least a bit newer version of ImgBurn 2.0.0.0 that can be downloaded from the Mirror 6 (Imgburn.com) site. The file size for that one should be 948,224 bytes. The first mirror (betanews) still has the older version you have.
  15. Hi blutach, Your guide about authoring with 32K gaps is what got me started on that, back when I was only doing single layer burns with Imgtool Classic - thanks so much for that! As this discussion progressed, it seems LUK and I agree that this has nothing to do with the 32K bug in ImgBurn, as my DVD didn't need it. Instead, this seems to be related to the type of issue that I've seen periodically. I believe that I have encountered it most often on single layer images. This makes sense since Derrow, the IFOEdit author states that this error is usually due to a package that is used to strip content (like trailers, DVD extras, etc.) in an effort to get it to fit on a single layer DVD recordable. Apparently it strips the content, without updating the sector sizes in the VIDEO_TS.IFO file? So, the re-authoring package is only paritally doing its job, and either IFOEdit and PGCEdit finishes the job, by deleting the references to the now missing content in VIDEO_TS.IFO, and correcting the ending sector information accordingly. Thus the VIDEO_TS.IFO/BUP files also shrink as a result of the deleted information. Despite the seemingly large reduction in size (25%), this has never been a problem, and all DVD features play fine (unless they were stripped, of course). Anyway, that's my understanding from the Google searching and reading I've done. So, it's not due to the 32K padding ImgBurn bug. It's simply that ImgBurn doesn't update the IFOs to "finish the job" of accounting for the information that was stripped from the DVD. Ford Man
  16. LUK and blutach: [LUK] I believe you are referring to the following post in the bug form: http://forum.imgburn.com/index.php?showtop...amp;#entry21926 Does the currently mirrored 2.0.0.0 version have this fix included? However, I looked back at the source files and all VTSs have 100K or more of VOBs associated with them, so the 32K padding never came into effect. Both PGCEdit and IFOEdit are apparenly only performing the correction that LUK mentions, but apparently these programs do the opposite - adjust the IFO file size to match the size written in offset 0x1C? Since 32K padding is not in play, I'm unsure why there is a difference between the .IFO/.BUP files written by PGCEdit and IFOEdit. In the past if 32K was not needed (or if I turned off the option in PGCEdit), then repaired files from both utilities would match exactly. Is there any utility that will provide a side by side comparision of IFOs in a format similar to IFOEdit's display? Binary comparison wouldn't help me much. I found a detailed explanation of this almost a year ago and can't seem to locate it again. Though I did find the following, excerpt from the IFOEdit author: "If the error: "There's something wrong...with end sector" apears, then go into the table 'VTSI_MAT', and adjust some of the table-start offsets, and try to resave the IFO file. This error happens, because if you strip something away, and the IFO tables gets corrected with IfoEdit, then it might happen that the new table is much smaller then the old one, what changes the start-offset for it." at: http://forum.doom9.org/archive/index.php/t-13084.html So, LUK - instead of the PGCEdit/IFOEdit approach of changing the file size to match the end sector (if that is indeed what it's doing), you will change the end sector to match the IFO file size? Since my DVD didn't require 32K padding after all, this seems more likely due to poor authoring versus anything that ImgBurn was doing, so your beta that is in blutach's hands likely wouldn't fix this, correct? Tonight I plan to restore the source files, run them through PGCEdit to perform the fix, and re-build the ISO with ImgBurn. Since the 32K padding is not in play, then this should work OK with my 3rd release ImgBurn 2.0.0.0, right? I suppose it's best to continue using PGCEdit/MKISOFS to build DL images that required 32K padding until the beta with the fix is released? Thanks, Ford Man
  17. This not really a bug, so I've posted it here in support. Both IFOEdit and PGCEdit are capable of parsing the sector addresses and sizes on VIDEO_TS.IFO and will correct sector addresses that do not match the file size. PGCEdit does this silently while IFOEdit returns an warning message. However both reduce the file size (all that I've seen) of VIDEO_TS.IFO (and VIDEO_TS.BUP of course). I built an image with ImgBurn 2.0.0.0 last night that I did NOT use PGCEdit on first, as there were no PUOs that I needed to turn off, nor any other adjustments to be made. ImgBurn happily made the image, which I mounted with Daemon Tools and then used QuickSFV to create CRC signatures, which I subsequently compared against the source files. All compared except for VIDEO_TS.IFO and VIDEO_TS.BUP. I noticed that Imgburn was changing a sector address, and as it apparently does so on the fly without altering the source files, the miscompare was not expected. However, out of curiosity, I decided to run the source files through PGCEdit and noticed that the VIDEO_TS.IFO and VIDEO_TS.BUP were shortened from 16K to 12K. I restored the original files and performed a "Get VTS Sectors" in IFOEdit. I received the following warning, which I've seen before, and from my research is likely the result of re-authoring and once corrected is nothing to worry about: "There's something wrong! The IFO Endsector does not match the file size." The resulting VIDEO_TS.BUP and VIDEO_TS.IFO are again 12K, as with PGCEdit, though the CRCs are different between the two programs, but likely due to the 32K option being turned on in PGCEdit. Meanwhile ImgBurn ignored the fact that the sectors were not consistent with the file size. Anyway, I realize that PGCEdit has undergone extensive development, and ImgBurn's image creation engine is in its infancy, and may not be intended to do all the things that these other utilities do to "fix" the source files. However, I saw mention by some that PGCEdit would no longer been needed with the advent of the ImgBurn build mode. My recommendation would be for the short term, at least, to continue running your source files through PGCEdit until/if this feature is included in ImgBurn. Of course PGCEdit also has the handy "fix streams" function that gets rid of the bogus extra audio and subtitle streams produced by some reauthoring packages, most notably CloneDVD from Elby. Ford Man
  18. Yes, then I expect that PGCEdit and/or MKISOFS is doing something wrong by reserving 2 sectors. After my post I did see that you acknowledged an error, had fixed it and would advise when the new version was available. I still have my source files for the one built image, so I'll go back to ensure that I don't have the 32K problem with that one. Will you be incrementing the builds as these small fixes are made? I've been keeping on top of the discussions and realize that you re-released 2.0.0.0 with the DST fixed on the date stamps, and then you re-released 2.0.0.0 again with the "verify against small image" issue fixed. I've been tracking the ImgBurn file dates and times to keep them straight, but others not "in the know" may have grabbed an older version of 2.0.0.0..... For such a major change, you and the beta testers seem to have really stomped most of the nasties!
  19. I built my first image with ImgBurn 2.0.0.0 and all went well - I was pleased to see that even the "period" (present directory) and "double period" (parent directory) directory entries were stamped with the desired time! No more messing with file dates and the system time manually before burning - great! I did use PGCEdit still to turn off the PUOs for the title and root menus from the copyright warning screen before building with ImgBurn. I used IsoBuster to examine the ImgBurn 2 image against some (but different) images built with the PGCEdit/MKISOFS combination. I noticed that on those built with PGCEdit/MKISOFS, the properties of the ISO file system (in the advanced tab) showed a difference of two sectors between the Root address and the PT address, while the ImgBurn Image showed only a difference of one sector. Meanwhile the PT length was the same (42) and the PT address precedes the Root address. I did look at a commercially authored DVD with IsoBuster, and it showed only one sector difference between these two addresses, so ImgBurn isn't necessarily wrong. If anything, perhaps the PGCEdit/MKISOFS ones are - for instance isn't only one sector needed between the PT address and the ROOT address if the PT is only 42 (bytes?) long and precedes the ROOT? I suppose I need to brush up on my DVD file system and structure. I just started poking around when I saw someone state that AnyDVD reported that an ImgBurn built and burned DVD was invalid...
  20. Ok, that's what I was afraid of. I'm anxious to try this feature out once I clear disk space! Any plans on adding a straight read mode for copying simple images to the hard drive for subsequent ImgBurn burning? I've been using ISObuster for that, and it works OK.
  21. Actually, I went back and looked and lfcrule1972 was correct that I did have two periods in a row, which I used to represent the parent directory entries that are shown from a command prompt. I changed them to words and then the reply worked! I would have never guessed that having two periods in a row would creat this kind of issue! However, I'm not sure why I was unable to come back and edit my message in this thread.... In the future I'll use a text file if I can't figure it out! Thanks lfcrule1972!
  22. Actually, what about disregarding the timezone altogether? If I want my files to have a time of 8:44, why consider at all the time zone and whether daylight saving time is active or not? Just simply put a time stamp of 8:44 unconditionally? Is this just the baggage of programming through with the Windows operating system - i.e., does it force conversion to local time and date stamps? I assume the time zone is also embedded in the file attributes somewhere? Nero had this same issue with time stamps, and they acknowledged it as a bug in a reply e-mail, stating that their intention was supposed to set the time to what I wanted regardless of time zones or DST. However, they never seemed to bother "fixing" it and I had to go through an elaborate routine to check whether DST was active during the date I was selecting, and if so, I actually set the desired time to one hour less than what I wanted so that when it advanced it would actually be what I wanted. Then if I wanted to be really obsessive, I would also change the system date and time right before burning so that the current (period) and parent directory entries (double period) (as vied from a command prompt) would have the same time and date as the files themselves, so that the DVD actually did look like it was authored on that date... This is actually what I've been doing to build dual layer ISOs with PGCEdit... I'll have to check out the ImgBurn build mode now - this looks promising, and I'm anxious to see how it handles all this. This looks great - thanks!
  23. I'm not sure what you mean by full stops, but I wasn't using any repeating symbols or letters. I was merely attempting to quote LUK's post about the file date problem. I even logged off and then back on, removed the quoted portions to no avail, and then when I came back to edit my original message in this thread, I couldn't do that either...strange!
  24. Test post: Received the following error when attemping to reply to http://forum.imgburn.com/index.php?showtopic=1788 thread: Forbidden You don't have permission to access /index.php on this server. -------------------------------------------------------------------------------- Apache/2.0.54 (Fedora) Server at forum.imgburn.com Port 80
  25. Great - what a time saver! Thanks so much for considering this... BTW, 1.3.0.0 has been working great - no new issues found with strangely authored ISOs....
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.