brit0n
-
Posts
38 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by brit0n
-
-
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.
-
Sorry but that is incorrect.
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.)
-
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
-
Thanks Lightning. VERY speedy result. Don't mind getting emails and then finding nothing - it means you beat us to it!
-
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.) -
Again, my 4 seconds is nothing like the 1 hour yours takes!
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"!)
-
You just might like to think before saying stuff like "I downloaded a torrent". If you know anything of LUK!'s previous experience, you will know that no-one wants it repeated.
So what did MY post contribute? Possibly the de-risking of the forum. Use YOUR brains in future.
Regards
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.
-
I took a single CD sized (approx) AVI file from a torrent
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?
-
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).
-
What if you only add 1 file into Build mode for buring? Does it still takes ages to parse the filesystem during a verify?
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).
-
44 minutes?!
That's 44 seconds and that's not even where the program does the parsing.
The parsing takes place AFTER the 'Device Ready' message comes up.
.....
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.
-
No, it only buffers what can fit in the allowed buffer size. i.e 20MB, 40MB etc.
Thanks - it makes sense.
That's not to say my tests came out ANYTHING like yours.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.
This was just me going from machine to machine via a router - running at 1 gigabit. The actual throughput didn't exceed 10MB/s though during the parsing.I didn't think it was bandwidth that was causing it even though it's a slower network.
I 01:11:52 Cycling Tray before Verify...I 01:12:36 Device Ready!
.....
Please note that this was burning to a DVDRAM hence the 5x max speed
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.
-
Not sure exactly what you mean or rather which mode you used etc
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.
-
What if you only add 1 file into Build mode for buring? Does it still takes ages to parse the filesystem during a verify?
How does that time change as you add more files?
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.
Oh and is the EXACT text in the status bar 'Parsing File System' or does it say something in addition to that? I'd actually made 2.3.2.0 change the status a bit more depending on what it was doing.The exact message 'Parsing File System' shouldn't actually be visible for all that long.
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.)
Just to be clear, this is with you burning + verifying an ISO file that you've already built yeah? Not one you're building on-the-fly direct to a disc?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.)
-
OK thanks for the explanation. Glad to know I hadn't missed something.
-
Might sound simple, but is there a way to let ImgBurn know that you are building for standard (no overburn) CD-R/RW? (I'm particularly talking about data/bootable CDs as there is no way to guesstimate their size before preparing the build). If I forget to manually check, I end up building an ISO too large to fit a CD and have to repeat the build.
(I seem to remember that Nero did this by showing a size gauge as you added files which showed if you had hit the limit, but then Nero already knew the intended device before you built an ISO - saving the ISO was merely an option instead of burning. Yeah, I know, Nero fails to do a lot of burning things since they started trying to be everything to everyone.)
Even if the device selected (when Output is set to Device) is a CD burner rather than a DVD burner, when I set Output to Image File the Advanced | Media only show DVD types and Custom. I have to manually check the Information panel before building to ensure that the ISO won't be too large for the CD-R/CD-RW. Should I be setting Custom to the CD size and will this mean that the Information will show before the build that the ISO won't fit (or would require overburn)?
Thanks for any advice.
-
OK I now tried ImgBurn Version 2.3.2.0 to build an iso (very quick) and then burn a bootable CD from it. ISO built from files/boot image on a NAS partition and saved to same partition. CD written from there. Verification delay (parsing file system?) remains more than one hour (1:21:30):
04:21:17 Cycling Tray before Verify...
04:21:23 Waiting for device to become ready...
04:21:31 Device Ready!
05:43:01 Operation Started!
Obviously, the problem does NOT exist if I move the source files to a partition on a disk on the PC running ImgBurn and burn from there so that is the method I use for working builds/burns. Just thought you might like the information in case sometime in future dev, you identify a possible cause.
To see if the CIFS was causing the problem in v2.3.0.0, I repeated the original build/burn sequence with the source and destination files on a FAT32 partition on another PC on the LAN. I got the same kind of delay. (I haven't repeated that test with v2.3.2.0 because it is unlikely to produce different results, but sometime soon I'll try it using a NTFS partition on another box on the LAN.)
This is a standard peer-to-peer Windows wired 100Mbps Ethernet LAN running on TCP/IP and in all other respects it operates fine including streaming video off those NAS partitions which is unusual for this setup. For me, it isn't an issue - ImgBurn is still so far ahead of the field that moving source files/ISOs from/to the PC running the program and then moving them back afterwards isn't too high a cost although it would need slightly different storage plans for DVD burning in order to have large enough partitions in the right place to do that, but again, cost is small. I just thought you might like to know there is something odd happening here. Am I really the only one having some weird delay when I do this through the network?
Lightning_UK, if you want me to try something to get you more information, let me know . I don't know if there is a way to get some kind of detailed report out of that period to see what is happening - I am happy to install something to do that if you want.
-
The Queue only applies to write mode, hence it's only visible in write mode.
That's the way it is and the way it'll stay I'm afraid.
Fair enough. Just a suggestion - I thought the queuing system might eventually allow other sequences. As you've managed to keep this amazingly complex software pretty darned simple, it makes sense!
Anyway, the important thing is - NOT A BUG!
That key isn't one I put there (or try to remove), it's just something the OS decided to add. I'll add it to the uninstaller code manually now though. Thanks
I was wondering about that. The famous stray Windows registry shell entries (from what I have seen so far, Vista cleans up after itself better). Thanks.
-
The title pretty much says it. I can get the View | Queue option showing sometimes. But not actually when I build an image with the Option "Add To Write Queue When Done" check box checked (even though it isn't checked by default which is interestingly different lol).
So I successfully build the ISO and there it is on disk. If I try to Exit ImgBurn, I get the warning dialog "There are some images still queued up for burning. etc"
Obviously I can burn the ISO, but not from the Queue.
I'm gonna try a complete removal of everything ImgBurn and reinstall this version after a reboot and then see if it still happens.
OK. So if you have to manually select Mode | Write in order to get View | Queue, make this a suggestion not a bug. If there is nothing queued, maybe View | Queue is disabled (greyed out). If something is queued, View | Queue is enabled. But in either case, may I suggest that Queue always shows in the View menu? (If it is supposed to already, this IS a bug lol)
(Incidentally, uninstalling from Add/Remove programs list leaves at least one Registry Entry. This is in WinXP Pro SP2. The first entry I picked up still there after uninstall, delete user folders which remain and reboot was a string value at:
HKLM\SOFTWARE\Classes\Applications\ImgBurn.exe\shell\Burn using ImgBurn\Command
Value:
"C:\Program Files\ImgBurn\ImgBurn.exe" /MODE ISOWRITE /SOURCE "%1"
That's shell. Haven't completely checked associations etc as I want to use the darned program lol
-
I sling it over my shoulder and tell her I'm a bell ringer.
An over the shoulder boulder holster suddenly takes on a new meaning - I mean they were supposed to be at the front and there were two of them when I were a lad, ba goom.
(Oh, technical? I missed the log entry which refers to the verification process but never mind cos that would make the testicular size even larger.)
Sorry not to come back with anything useful - the temp here in Georgia just decided not to require the usual air-conditioning and I hadn't prepared for more winter so it's log-splitting time again
-
Also, it's a little hard to estimate progress on something you don't really know the size of - that's the whole point in parsing it!
OK. So either I missed it if it already exists (can't find it yet, but this software of yours has a lot of combinations of options for its configuration) or the suggestion should be different. Can we build and burn OTF AND save the ISO in a single step? I have some burning software on a box here somewhere which doesn't TELL you it will, but which, when you finish an OTF burn asks if you want to save it. I assumed that if I set it up to build and burn, there would be an option before starting to save the ISO (and then supply its destination) but assume means exactly that. Apologies if I missed it. But surely if ImgBurn knew in advance that I wanted to DO that, it would save extra effort as it wouldn't need to parse the filesystem as it already built the darned image it was burning. Just a thought. I suppose the a separate verify might work for the ISO but that wouldn't need the burner and could be done in the background. Maybe I am wrong in thinking that verification would be quicker/simpler if the program knew that verification was required before the build/burn/save_ISO started.
We often still (or at least I do!) call it 'building an ISO' even if it's on-the-fly. 'building a disc' doesn't quite sound right. I often add the word 'directly' when i mean it goes straight to disc rather than to an image file. Oh and lets not forget it's called 'build' mode, hence 'build/building/built' gets thrown around a lot anyway.Oh well, language and semantics. Like the age-old question "does compile mean build and save/burn or just build?". Compilation used to mean getting the stuff together which actually meant you didn't even NEED a CD/DVD drive, let alone a burner or any software to do it. Which is probably why we use build so much.
In any case, I seem to have had one of those moments last night some time. Sorry and delete any posts that need deleting. I am working so many different types of forums, I am probably not getting the level right.
There was a bit of semi non-sequential reading going on and I can only guess that might be what was playing havoc with your NAS. That's not to say the changes I've made will perform miracles! An hour and a half to parse the filesystem sounds somewhat ridiculous! Over my LAN, I could probably have an ISO with a billion files in it and it wouldn't take that long!Let's just wait and see if 2.3.1.0 is better for you.
OK. I'm about to run the comparison test as one of the boxes is just about to finish some bench-tests on something else so if I can stay awake, I'll try it and then use the same box/build for 2.3.1.0 and see what the difference is.
If there is anything useful out of either of them, I'll provide the technical stuff that might help you. I'm not impressed with NAS drives compared with an old box doing nothing but storage, but they are cheap which might explain it lol
-
I've used many NAS units in the past. Even one running NASLite on a Celeron 333. The speed wasn't great (around 6MB/sec) but it was certainly acceptable and usable.
Hence the need for me to test the difference. Sorry if you were joking and I took it wrong. Testing is usually taken as a good thing which saves the devs time provided they get accurate feedback.
The same might be asked of a new member jumping into a help forum and proclaiming that the software doesn't work properly.I said that? Before you responded to a simple suggestion? Sorry if I did. But actually, if I wanted to say it didn't work, I would report a bug.
We build and burn hundreds of images before each major release. We can't test every piece of hardware but if it took 90 minutes to parse and process 8gigs of data from a network device, we'd have noticed. Given that you obviously have a problem with the way ImgBurn handles files from your NAS, how about giving us some info on the NAS in question so we can see what it is? It's not one of those Netgear SC-101 things, is it?No it isn't. But as I said, if it IS the NAS (I haven't had time on any of the boxes to run a true comparison test without which I would be wasting YOUR time!), the test will show it. And if it does, it probably needs a different suggestion..... coming up....
Look, Shamus, sorry if I responded wrong. But I don't spend time typing on boards to do anything other than help - either the devs for the time they have already given ME, or to others (once I know enough about the software) to save the devs having to do EVERYTHING.
-
amazing we are still playing with floppy disks when the drives are museum pieces anyway
We aren't.
Regards
You may be - we aren't (well, except when our clients need us to).
El Torito standard for booting disks requires the use of a floppy image. If you have a bootable disk, you have a floppy image on it - you can't SEE it, but it's there. If you only use Linux, you are still using an old-fashioned DOS type diskette image.
It's a hack/kludge to enable bootable CDs and since it works, noone has bothered to come up with another standard which would have to be ground into everyone past all their complaints.
Got a better idea? Let's have it!
-
I think Shamus just meant, why didn't you build on the fly from the NAS rather than going via an ISO file?
Also, it's a little hard to estimate progress on something you don't really know the size of - that's the whole point in parsing it!
You've lost me. Why would you go through all this crap instead of building an ISO directly from the NAS unit?
It seems I just do it the easy way to suit my intellect 
!! Well guys, considering I was making a simple suggestion for some (possibly way in the) future small improvement to this great program, it's interesting.
Lightning, if Shamus meant that, surely he wouldn't have put "building an ISO" which where I come from means making a file which is saved on a disk. Anyway, I explained as I thought he must want to know why....
#036;lfcrule so do I. The easy way to do what I needed to do (which was to test the program to see if it could do it actually, which it can't - so far anyway, but the tests go on as with the other burning programs) was what I did: with all the files required for the build (IMG for the boot and contents files for the CD) on NAS and requiring both an ISO saved to disk and a burned CD, I built and saved the ISO from/to the NAS and burned it from there. Moving it would NOT be simpler, but I said I would do it because it TESTS my theory that it would be a LOT FASTER.
Any questions or are you attempting a put down job on a useful forum (i.e. being trolls)?
Power Cut Interrupted Burn
in ImgBurn Support
Posted
Just checking. And just one coaster lol
I should have checked the Severe Thunderstorm warning and left it until today!
Thanks.