Jump to content

FlimsyFeet

Members
  • Posts

    10
  • Joined

  • Last visited

FlimsyFeet's Achievements

ISF Newbie

ISF Newbie (1/5)

  1. The reason I asked the question is that I recently tried burning a DVD-Video disc that had an AVI file in the root directory. Although it seems like bad practice and is probably not to be recommended, it sounds like such a disc does not contravene any standards or specs. I used the "write files/foler" to disc mode of ImgBurn which led to the following interesting "conversation" (paraphrased as I can't remember the exact warnings): IB - You have a VIDEO_TS folder, so I'm assuming this is a DVD-Video. Do you want to change the filesystem to ISO 9660 + UDF? Me - Yes please. IB - The disc contains an AVI file, so I'm assuming this is a DivX video disc. Do you want to change the filesystem to ISO 9660 + Joliet? Me - Er, no, I've just told you I wanted UDF, so why are you asking me again?
  2. I just wondered if there is any sort of official specification anywhere for the naming of folders on a DVD-Video disc. My understadning from various sources is that there should always be a VIDEO_TS and an AUDIO_TS folder, the later is always empty but should be included for compatibility with DVD players. Some DVDs also have a JACKET_P folder which contains some sort of thumbnail image for the disc. Files for reading on a PC are usually placed in another folder - I don't have any discs to hand, but is this usually called DVD_ROM or DVD-ROM, or can it be any name? Do files intended for a computer have to be in a separate folder? I think I've seen some autorun type files placed in the disc root in the past. Is this allowed under the DVD spec?
  3. Question is as topic title. I ask only out of interest really, because recently I noticed that 2 MDS files that I expected to be the same were different: 1. create an ISO/MDS in build mode from VIDEO_TS folder on the hard drive 2. burn this image to DVD+R DL 3. create ISO/MDS image file from this disc A CRC32 hash shows that the ISO's created in step 1 and step 3 are idewntical, but the MDS files are different, I assume the layer break position has not been changed, so I just wondered where the difference comes from?
  4. So presumably then, if the image has been authored with a layer break set in the IFO, then there would be only one LB option presented? Sorry if I'm sounding a bit thick, and thank you for the information (and your patience...)
  5. Ah, I see... I've been rebuked by ImgBurn in thge past for selecting the ISO to burn instead of the MDS, now I understand why. So, for the sake of clarity, let's say for example I've deleted the MDS by accident, or I have an image file created by some other application which doesn't output an assocaited MDS file with it. I can use Tools -> ISO -> Display IFO Layer Break Information to show where the layer break is supposed to be, does ImgBurn use this if I attempt to burn an image file that doesn't have an MDS file with it?
  6. Prpbably a stupid question question regarding this guide: http://forum.imgburn.com/index.php?showtopic=6380 If copying a dual layer DVD disc (no CSS) what happens with the layer break position? Is it written to the ISO file created during the 'read' process, then used to ensure it's in the same location on the burned disc during the 'write' process?
  7. OK I tried the other DVD-R DL on another computer (also has a Lite-On drive, but a different - older - model). This time, the actual burn seemed to go OK, but ImgBurn froze at the Synchronising Cache stage and would not cancel (until I physically ejected the disc). Even though ImgBurn didn't close the track and finalise the disc, I can see the files on there, but haven't yet verified if they are completely intact. Looks like you were right! Log: ; //****************************************\\ ; ImgBurn Version 2.4.2.0 - Log ; Thursday, 23 October 2008, 20:50:42 ; \\****************************************// ; ; I 19:53:02 ImgBurn Version 2.4.2.0 started! I 19:53:02 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 3) I 19:53:02 Total Physical Memory: 1,048,048 KB - Available: 694,508 KB I 19:53:02 Initialising SPTI... I 19:53:02 Searching for SCSI / ATAPI devices... I 19:53:12 Found 1 DVD
  8. Thanks. I've now updated ImgBurn. Drive firmware was already the most current version available. I've burned dozens of DVD+R DL discs in the past with no problems - so it would seem this drive just doesn't like -R DL, threw a strop and reset itself. I still have one Verbatim -R DL left, probably best to try it with a different drive.
  9. I love ImgBurn - it's gereat that you can trow a load of IFO/VOB files at it and it's clever enough to ask if you want them in a VIDEO_TS folder. It's also clever enough to ask you if you want to erase a rewritable disc if it's not empty. However, do both, and it goes something like: disc not empty, erase? yes - erase disc - then check files - looks like a DVD? yes - make VIDEO_TS then burn I would prefer something like this, to get all the interaction out of the way at the start, so you can leave it and forget it: disc not empty, erase? yes - check files now - looks like a DVD? yes - now erase disc, then make VIDEO_TS then burn
  10. Changed to UDF file system because one file is too large for JOILET, but I've burned UDF discs before with no problem. Going to try the obvious - update ImgBurn, check for firmware updates, but is there anything else I should be considering? Log file for failed burn: ; //****************************************\\ ; ImgBurn Version 2.4.1.0 - Log ; Monday, 20 October 2008, 21:02:27 ; \\****************************************// ; ; I 18:58:55 ImgBurn Version 2.4.1.0 started! I 18:58:55 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 3) I 18:58:55 Total Physical Memory: 1,048,044 KB - Available: 541,852 KB W 18:58:55 Drive P:\ (FAT32) does not support single files > 4 GB in size. I 18:58:55 Initialising SPTI... I 18:58:55 Searching for SCSI / ATAPI devices... I 18:58:55 Found 1 DVD
×
×
  • Create New...

Important Information

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