Jump to content

brit0n

Members
  • Posts

    38
  • Joined

  • Last visited

brit0n's Achievements

ISF Newbie

ISF Newbie (1/5)

  1. Just checking. And just one coaster lol I should have checked the Severe Thunderstorm warning and left it until today! Thanks.
  2. I am guessing the answer to this but just to be sure... If a burn is interrupted by a power cut, is there any procedure in ImgBurn to attempt to continue where it left off? I realise the DVD may be damaged rendering it unlikely, but assuming that the head retracted safely, can ImgBurn recognise a partial burn of an ISO file to a DL DVD (with a .dvd file which notifies the layer break info)? Thanks in advance for the help.
  3. Don't be sorry - my apologies for getting that wrong. Didn't realise how recent the query was or I would have left it for you guys. 1. So when I attempt to "force" the write speed to 1x, in fact the drive/media combination may not be able to work that slowly? 2. And if so, ImgBurn (being smarter than the average burner) knows I am dumb so doesn't point this out and carries on with speeds the drive/media CAN support? Which is why when I tested after answering that question, with drive/media combo that I have AWS rated at 2.4x but I have "set" at 1x cos I don't mind how long it takes, I see speeds varying between 2.3 and 2.4? And does that suggest that the AWS rating of 2.4x is probably correct? 3. Back to the OP's question. Does that mean there is no way to "throttle" the write speed to the slowest possible or is that effectively what setting 1x is doing? Or will setting the AWS still allow ImgBurn to throttle back if it needs to? (and yes, I just re-read your excellent guide to AWS but I am still not sure on this point.) (To explain why I am asking Q3, whenever I let a 2.4x rated DVD run at AWS of 2.4x, it won't auto-start in Windows and takes slightly longer to get loaded when I stick it in a regular DVD player whereas setting it to 1x seems to remove these issues.)
  4. Yes. You can burn at any speed you like but obviously if it is faster than the drive/media combination can accurately burn at, you are going to make coasters. If you manually enter 1x in the Write Speed scroll down box on the right when you are in Write mode, that is the speed it will burn at. If you are setting that at 1x or 2x, I don't see where you are seeing that it is writing at 4x. Perhaps you can elucidate! Note that this is incorrect - see below
  5. Thanks Lightning. VERY speedy result. Don't mind getting emails and then finding nothing - it means you beat us to it!
  6. Well it's always interesting getting a suggestion to go Open Source. But you can use ImgBurn in all Windows flavours that matter and you can run it under wine in Linux. If you are an Apple user, I have a feeling you already have a burning program you are fond of. So going Open Source would achieve er.... well, for a start, it would mean that any further development/improvement of ImgBurn would be by committee decision and OS compromise. AAAARGH! PLEASE DON'T! (If anyone actually wanted the code (without reverse engineering of course), all they have to do is to open up some kind of Borland C++ Builder (what? you don't have one?), reinvent all the dialogs etc that LUK has created to make it easy for us all to use and then work out what the code would be for each and every button on them. Easy really. Piece of cake. Definitely won't take you a quarter of the time LUK spent so far. And there you'll have it - your very own source code! Probably only take you a few years if you work nights.)
  7. Yes, I got that - when I put my brain back in gear and read the logged times correctly! The single file (plus boot image) test showed it was file numbers/quantities causing the hour plus period. The later test I did, I observed the status bar text - results posted above. The long activity was Parsing UDF File Sustem... which was what you thought it probably was. Verifying when burning from local disk took even less time on CD-R than CD-RW (the whole parsing thing was logged at 1 second). I am guessing the length of this stage is simply a sliding scale thing which gets worse the more small files included in the ISO (you intimated that in an earlier post). If so, ImgBurn and any other burners aren't going to do anything different unless they save a detailed file system file alongside the ISO which isn't very much use (I think it was Nero that tried it for a while a few years ago and gave it up). Lightning, let me know if you want more tests/information with varying number of files, but I think we're done. (If anyone ELSE wants to try this to see if they get similar results, say with a different network setup, all you have to do is dig out an old OS installation CD, copy the files from it, fill it with other files, fill a 2.88MB boot image and build the ISO or you could probably just download a Linux ISO - find one of the bloated distros. You don't have to be able to USE it or break any copyrights - the ISO simply has to contain large numbers of small files (maybe you have one of those CDs from the photo processing lab which contain a gazillion different types of thumbnails and different resolution images from your vacation in Biarritz lol. Just so long as you have large numbers of small files, a full CD's worth in the ISO and the ISO stored on a remote storage device so that ImgBurn has to work through the network. Burn it from there and verify.) If anyone has an ISO with large numbers of small files (this will almost certainly be a DATA or GAME CD) and tries burning it from a remote storage device with verirification and finds that ImgBurn seems to "hang" after the write is successfully completed but before the verify phase gets going, copy or move the ISO to the PC doing the burning to speed up verifying. OR start the operation, tell ImgBurn to shutdown after completion and go and do something else. (By the way, ImgBurn works better in the background than any other burning software we've tested so far - "another great feature"!)
  8. It must be a UK thing. I may be British, but people here use Torrents for a whole host of things. Our main use on this network is to share very large chunks of data. Government departments use them for (mis)information etc. It was just a file the right kind of size. Apart from the size and type, the only other thing I needed to know about it was that it didn't have any malware. But point taken.
  9. You just lost us brit0n - well, me at least. Most of these AVIs are of copyrighted material. This forum is about helping people with burning, but not when they are downloading stuff from torrents. Regards I read the forum rules and I totally agree with you. I took a file which fit the test I needed to do. I didn't break any copyrights and I didn't condone anyone else doing so. As it happens, the file I used is a public domain file released by the U.S. Department of Homeland Security but I only chose that one because it was about the right size. I have NO idea what is on it! So tell me, what is your problem? I was trying to help here - you think I NEED to be doing these tests? I thought Lightning might want the info and I am happy to spend a little time getting it. What did YOUR post contribute to these forums?
  10. Here's extracts from the log for a similar ISO as the original ones I reported, but after removing 66MB in 3,102 files in 77 folders (no extra files added so the overall size is somewhat less): ; ImgBurn Version 2.3.2.0 - Log ..... I 22:13:14 Operation Successfully Completed! - Duration: 00:20:44 I 22:13:14 Average Write Rate: 601 KB/s (4.0x) - Maximum Write Rate: 626 KB/s (4.2x) I 22:13:14 Cycling Tray before Verify... W 22:13:20 Waiting for device to become ready... I 22:13:28 Device Ready! I 23:22:09 Operation Started! ..... I 23:33:58 Operation Successfully Completed! - Duration: 00:11:49 I 23:33:58 Average Verify Rate: 988 KB/s (6.6x) - Maximum Verify Rate: 1,256 KB/s (8.4x) Approx timings of status bar text (HH:MM): 22:13 Checking File Systems... 22:14 Parsing UDF FileSystem... until 23:21 Parsing UDF FileSystem... then other items too fast (see log) until 23:22 Verifying Sectors... and then continue normally. So the long activity shows Parsing UDF FileSystem... For me, the answer is the workaround when using these kinds of ISOs - data disks with plenty of small files (some games might have that problem as well as OS install disks, but they are comparitively easy to move to local disk for the write. There is no problem with Movies/Music etc where most of the content is in one or a few files. If you want me to further reduce numbers of files, I can. The removed files did indeed shorten that time, but it is hardly significant - I didn't add any files to make the size similar either. The files in the boot image don't affect it adversely at all so I presume that is verified as a single IMG file. Presumably the CAB files are also treated as single files - I can't believe that verification goes inside them because if it did, it would probably take 12 hours or several days instead of 1 hour! Hope this helps in some way even if it is just to make you leave well alone! (Maybe amend that status bar text to something like Parsing UDF FileSystem (may take a while)... so users don't think it is hanging and crash the program never to use it again lol (if they haven't sensibly gone to bed and left the queue to run through and shut down).
  11. OK, back on track (I think), Lightning. Slow but sure lol I took a single CD sized (approx) AVI file from a torrent and build it to an ISO using the same source/destination machine/storage device. This bit will sound weird if anyone reads it not realising this was simply a test..... I made the CD bootable using the same 2.88MB boot image full of small DOS files as the previous burns. No significant lag - extract from log: I 22:29:36 Cycling Tray before Verify... W 22:29:42 Waiting for device to become ready... I 22:29:51 Device Ready! I 22:29:53 Operation Started! ....... I 22:39:33 Operation Successfully Completed! - Duration: 00:09:40 I 22:39:33 Average Verify Rate: 1,199 KB/s (8.0x) - Maximum Verify Rate: 1,255 KB/s (8.4x) The only oddment was that it asked for another CD, but I probably went over the size limit (the previous time I tried it, it simply warned me before I started, so I changed to a smaller file - dunno what that was about, but I need to read the forums to learn what the options for that are - I seem to remember seeing an option to automatically divide large files). I hope that didn't make a difference, but as it verified that disk, I can't see how it could. So as I see it "so far", the obvious advice for anyone burning a disk from an ISO on a remote storage medium where the ISO contains many small files is to move the ISO to the burning machine. Hardly something you can change ImgBurn to do anything about unless it is gonna count files/filesizes which is a little off the map compared with the average user! I'll test sometime with the largest number of small files removed from that other build and see what happens and let you know. (That's only going to remove approx. 50MB but that's 2,433 files in 53 folders so it should show some kind of difference if that is the cause of that long period.) And I'll let you know what the status bar is showing during any long period for the original burn when I can do that one "attended". One question.... hope this edit is before you reply: Would verification look inside .CAB files? If so, I would need to remove those and test too (you gotta KNOW Windows has a lot of CAB files).
  12. Sorry, I slipped a cog - my bad! I'm trying to fit a different activity monitor on the LAN so that I can see whether I am right in thinking there is no continuous activity during that hour+, but Windows is fighting me lol. I'll let you know when I try the single file etc runs.
  13. Thanks - it makes sense. I remember noticing when letting a DOS batchfile copy the Win98 directory off the CD onto HDD it goes through a terrible phase when it hits large numbers of tiny files - Tour or Help stuff probably. It is probably that. I didn't think it was bandwidth that was causing it even though it's a slower network. Well, I could use the DVDRAM but it isn't the burn speed I am worried about. What is a relief is that you had 44 minutes in that "lull". So it isn't just me cos that is a significant time. But if that's what it takes to verify a large file group, so be it! Everything has its cost and this one is easy to work around. When I try again, I'll let you know. Thanks for all the help and info.
  14. OK. We are talking the following: Build Mode: Build an ISO to make a bootable CD from files on a remote machine on a Windows P2P LAN. ISO destination on the remote machine. No problems, very fast, great! Now ignore that because unless ImgBurn is weird, once built, saved to disk, log updated to show build is complete, it won't remember what it just did except that the Queue will now show another action which is: Write Mode: From that ISO still on the remote machine, write to CD with verification. No problems, very fast, great ..... IF you don't verify. Which is why I am only quoting that small part of the log. It's a LAN thing, not a processor/memory limitation. But we're talking minutes for the build and for the burn and for the verification itself so it's only this phase we're talking about. The only oddment is that it is a bootable CD and contains many (some small) files - the one I keep repeating so that it is reasonably consistent is a standard Win98SE install CD with some drivers and other stuff on it which makes it nearly full. The boot image is standard El Torito using a 2.88MB diskette image which again is about full of DOS files. L_UK knows the phase and seems to have spent quite some time wandering around that area of code. The only reason I can think of for him to bother is that this is a fairly standard setup which more and more people may use (more network storage being used for huge BitTorrent etc downloads - more media center PCs hungry for more burned DVDs) so this delay might put them off using ImgBurn more than once. That would be dumb as the workaround is TOO simple - move the stuff to the PC doing the job, save the ISO there and then archive the ISO somewhere else if you want to keep it. I'm only doing the remote thing any more so that I can feed back. If L_UK wants to drop this, I can go back to moving the stuff which is quicker, but I'm happy to try to identify the little beggar which is causing that seemingly nasty hour+ extension. I am just hoping it isn't some dumb Windows networking thing.
  15. If I get this right, in order to check that, I have to build ISOs with differing numbers of files in them and then check that time lag each time? I'll do that when I get a chance unless I see here there is a different way. I need to check that. I missed that in the release notes so I didn't watch it. (To be honest, I was kinda hoping with this version that it would flash past too quickly for me to see lol.) Yes, ISO to Burner. ISO remote on the LAN. The only connection is that the build immediately precedes the burn and is auto-queued, but I understand that ImgBurn has to forget the build and sees the ISO as just another ISO and starts from scratch. So I assume I can do tests with previously built ISOs already sitting there. I haven't actually noticed it with an on-the-fly burn, but unless I am misunderstanding how it is verifying, it will already have the file system under its belt even if the files are remote on the LAN. It'll be a while before I can check enough to make sense, but I will get back when I have all those answers. One question that arises - if I have 2GB RAM and we are talking a standard CD burn, does ImgBurn actually go back (and forth) to (and from) the ISO to verify or does it hold it in memory? (I ask because this is all caused by the ISO being on the LAN.)
×
×
  • Create New...

Important Information

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