Jump to content

LIGHTNING UK!

Admin
  • Posts

    30,457
  • Joined

  • Last visited

Everything posted by LIGHTNING UK!

  1. As ImgBurn doesn't (yet) create images from files, it's not really its job to make/set/align the layerbreak position. The thing people generally assume to mean 'layerbreak' is just a flag in one (or more if their LBA is the same) of the cells mentioned in the IFO. There is nothing in the vob to signal where it is. ImgBurn will parse the filesystem and look for vob files that lay with the acceptable LBA range. ie. the middle LBA of the file (minimum) and the original layerbreak on the media (before it's changed - that's the maximum). If it finds a vob between these points, it will read its associated IFO file. It then looks through all the PGCs within those IFO files to see if any of the cells are already marked with the 'I'm a layerbreak' flag. If it finds one, it add it to the list of potential layerbreak positions. If it scans all the cells and none are marked with the flag, it checks them again to see if they start on an LBA thats a multiple of 16. These then become a potential position for the layerbreak and are added to the list. Once that's all done, the list will hopefully contain a few potential positions. If it doesn't, the user is warned of the dangers of burning the disc. If it's not empty, the list is displayed to the user in a dialog box (if there is more than 1 option). They can then choose which one they want to use. If the selected position didn't have the flag set, ImgBurn sets it. Burning then continues. Of course none of that needs to happen if the user is burning from an MDS file where the layerbreak info is already contained within it.
  2. There are no settings you need to change. The defaults work the best, that's why they're default!
  3. No idea how to do any of it, I've never looked at recode! lol You just need to check any pair of IFO/BUP files. If there is no VOB between them, so much the better. If a vob is ever > 32k in size, forget about looking at that set - they will always be > 32k apart. (That's because it goes _0.IFO, _0.VOB, _1.VOB, _2.VOB.... _0.BUP)
  4. With the right drive, they're excellent. http://forum.imgburn.com/index.php?showtopic=551
  5. You could probably experiment and find out for youself. To test, you need to make it so that any _0.VOB file it makes is Then look at the image within ISO buster and see if the (end of the) ifo and (start of the) bup has at least 1 LBA address between them that's divisible by 16. It's not a major thing and certainly nothing to do with ISO or UDF specs. It's probably just advisable for DVD-Video because if the IFO and BUP are in the same ECC block and that gets ruined, there is no chance of reading either of them - making the 'BUP' file pretty pointless as its purpose in life is to be a backup!
  6. Yes maybe it was a one-off. I guess it does depend on how the drive handles the command though. Maybe when you move the layer break position your drive is actually filling the gap (burning) between the old one and the new one. It's totally down the the manufacturer and the firmware really. Leave the 'check for updates' enabled in the program and it'll tell you when a new one is released - assuming you actually run ImgBurn from time to time! Also, you can check the website. Version 1.2.0.0 is right around the corner.
  7. SAO -> DAO was just a name change, nothing more. The correct term for DVD burning is DAO. Setting the L0 capacity is down to your drive. If it's taking a while, it probably doesn't like the discs much. ImgBurn just sends 1 command to the drive, that is all. Make sure you only use Verbatim DVD+R DL media.
  8. You're still leaving yourself open to a 'lost update' type of event. Sorry but this won't be happening any time soon.
  9. Data wise, there shouldn't be, no. The table of contents will probably be different because one would have burnt mode 1 sectors, the other would burn mode 2 sectors. You should just burn the bin file. The only time(s) you cant burn bin+cue with ImgBurn is when the CUE mentions audio/mp3 (i.e. you're burning an audio disc), or when it contains multiple sessions/tracks. When you're converting that file, you're stripping off the header sequence, the EDC and ECC regions. They're what make up the 2048 -> 2352 bytes per sector difference. It's a pretty pointless exercise to be honest!
  10. Found this just now too... http://www.litepc.com/support/kb.cgi?view=74
  11. LIGHTNING UK!

    FAQ

    Problem: I get an error message saying that the required 'shfolder.dll' file is missing. Answer: You must be running a VERY basic installation of 95/98 etc without an up-to-date version of Internet Explorer installed. Normally this file IS already on the pc. Visit this link and download a package (containing it) from the Microsoft website. http://www.microsoft.com/downloads/details...D6-DBFA18D37E0F Well, it's that or update your installation of Internet Explorer.... or better still, your operating system! Update - March 2020: shfinst.exe seems to have been removed from Microsoft's servers (and most of the internet!). I'll attach a copy here instead. shfinst.exe
  12. Blimey, how did you manage to not have shfolder.dll?! I've personally tested ImgBurn on 95, 98, Me, NT4, 2000, XP and 2003. Never once did I come across such an error. Have you got a build of 98 there with NOTHING else installed? At the very least I'd have expected Internet Explorer to install that file - if it's not already in the base build. The link below lets you download the proper package (containing that file) from Microsoft's website. http://www.microsoft.com/downloads/details...D6-DBFA18D37E0F
  13. They're in different PGCs. Yes, chances are they're taking slightly different routes through the cells so they can change languages somewhere or something. i.e. PGC 1 plays cells 1,4,5,6,7... PGC 2 plays cells 2,4,5,6,7... PGC 3 plays cells 3,4,5,6,7... 1, 2 and 3 are all roughly the same but maybe the logo is in a different language or something. Honestly, your guess is as good as mine! No comment on the decrypter stuff, sorry.
  14. What do you mean 'which disc' ? It's either all of them or none of them! If your player can play DVD+R DL with the booktype left at DVD+R DL, there is no real point in setting it to DVDROM. Unless of course you take them to somewhere that can't play them when left as DVD+R DL. To be on the safe side, just set all of them to DVDROM. Doing that will certainly not make them any less likely to play.
  15. lol, you've got waaaaaaaaaayyyy too much free time on your hands if made all those up!
  16. No, stick with the MDS file if you have one. I'm just saying that ImgBurn CAN calculate the layerbreak position from the IFO files now if it needs to. The MDS one is still the best and it saves a lot of messing around - although that's all performed by the program of course, it's no extra work for you!
  17. Yup, like I said, they're all the same. Just click one of them and hit ok.
  18. Most older players probably prefer it to be set as DVDROM. If yours works ok when it's on DVD+R DL, you have no real reason to change it. That said, it's the 'norm' to set it to DVDROM. Some drives do this anyway and you (the user) has no choice in the matter. Just make sure you're on the latest firmware for the drive so you get the best burns from it.
  19. ImgBurn doesn't NEED the MDS file to get the layerbreak position right. So long as the image is correct, it will parse the IFO files and find where it should put it. That's the major difference. It adds a bit more info to the log for people that like to know exactly what's happening, stops you from doing some silly things and of course you can now view the burn speeds in a nice graph using DVDInfoPro. Other than that, I don't know of any way to improve upon what DVD Decrypter already did! Put it this way, there is certainly no reason NOT to use ImgBurn over DVD Decrypter for burning suttf.
  20. It's also the only way to perform a 'real world' verify - unless of course you don't ever intend on taking that disc out of the drive Sometimes drives can burn ok, but after cycling the tray, they decided the can't read back what they've written and fail to initialise (internally I mean) the media. As such, no software can read anything back from the disc as the drive always says it's 'not ready'.
  21. Again, this comes down to something actually changing the error codes the drive is returning. I honestly can't see that happening! Driver wise, all you can do is get the latest chipset drivers and ata (application accelerator - might be called Raid Matrix or something now?!) software from the Intel site. That's what I do and (touch wood), mine is ok! Mine is the Intel 875 chipset, not sure what you have on that board (and I'm too lazy to search google )
  22. No harm done. Sorry we couldn't help you.
  23. Same difference really, it just can't write to the media. RMA time!
  24. Eh?! Clearly that's the log of it FAILING to WRITE a disc - and it's not going to verify until it's written something properly! There are few things that look odd in that log but starting at the beginning.... go and update your drives firmware. http://forum.rpc1.org/dl_firmware.php?download_id=750 Get the 1S34 one.
  25. I always use SPTI and therefore it undergoes the most testing! Stick with it unless you really have a reason to change! Glad you sorted out the crappy playback issue but I've no real idea why your buffer drops when you open something, it could be a virus checker or something. Basically it could be anything that locks out other processes while it does it's own thing. For the programs main buffer to drop off, it must be unable to read from the hdd quickly enough to keep it full. That's where the bigger buffer will help out. As you have plenty of RAM, that shouldn't be a problem. A second hdd away from the main OS drive would still be a good idea though
×
×
  • Create New...

Important Information

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