Jump to content


  • Posts

  • Joined

  • Last visited

About Bosanek

  • Birthday 09/07/1985

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    Bosnia and Herzegovina
  • Interests
    SCSI mass storage systems, vintage PC hardware, philosophy, linguistics

Bosanek's Achievements

ISF Newbie

ISF Newbie (1/5)

  1. And even more easier IMVHO, or better say the easiest way, would be if ImgBurn would support the option to choose an available optical drive to perform the verification after the writing phase.
  2. OK, thank you both for your suggestions. A side note: It's just a pity that nowadays drives come with miniscule buffer sizes, so they rely on BURP as a measure of solving buffer underruns. In my opinion BURP is the worst "cure" for buffer underruns, because a BURP point is equivelant to a steel welding point - it is a patch in essence, which can never be as sturdy or as reliable as a solid piece of work. The only good side of BURP is that it completely eliminates the chance of failed writes which are caused by data feeding insufficiency, so that Joe won't get mad and call optical producer's tech support saying that his drive is not working (because it failed to write a disc because of BU). BURP ensures that ordinary Joe probably won't ever know that his drive is patching his PC's inefficiency very often. Large buffer sizes, on the other hand, do not completely eliminate a chance of buffer underruns, but they are a far better solution in general, because with a buffer size which would give you for example "grace time" of 4 seconds, a buffer underrun would be a well deserved one indeed . Such a drive would "endure" system overloads in most cases, and the burns would not have welding points. My Yamaha CRW8824s (a 8x8x24x SCSI CD-R/W writer from 2000) has a 4 MB buffer, giving me over 3 seconds of grace time (4 s / 1.2 MB/s = 3.33 s). I have never had a buffer underrun with it, and it is still working flawlessly on my Pentium Pro. On the other hand, my Plextor PX-755A has a 2 MB buffer, giving me only ~90 miliseconds of grace time on 16x DVD writing speed. Since I write at 8x, that time is 180 ms, but that is still a hair thin and fragile. If the drive had a 32 MB buffer (and AFAIK, cache RAM on optical drives is dirt cheap these days, as any RAM is), that would provide almost 3 seconds of grace time on 8x DVD writing speed, what would be very good. But as I said, it is commercialy more desirable to have BURP instead, because Joe won't notice the problem at all and won't bug the company. ===== Al this text has nothing to do with the subject or ImgBurn, this was just mine own opinion on the general matter, and excuse me for taking ~3 KB of your storage space for this message .
  3. As I mostly write discs for archival purposes, I want top-quality writes, so buffer underrun points are very undesirable, although they are not fatal. That is why I must know of every occurence of a buffer underrun, with an exact LBA where it happened. So, are you saying that the message "Waiting for the buffers to recover" (which I have never seen) in fact represents an ocurrence of a buffer underrun? In other words, is this message a reliable indicator of a buffer underrun? And does it display a LBA at which the buffers were emptied? If not, I highly suggest adding that info, if it is possible for ImgBurn to know that.
  4. That is a very good idea indeed. But, as a replier said, that can also be done manually, using the method which he described. Anyway, it would be nice to incorporate the choice of a drive in the "verify-after-burn" phase. I would not consider it a high priority request though. Add it when you get more time for lower priority work on ImgBurn.
  5. Hello, does ImgBurn report the occurences of buffer underruns in its log? I am asking this because I have a Plextor PX-755A, and I wrote a MCC 03RG20 (Verbatim DVD-R) using PlexTools 2.35 at 8x. There were no other running processes on the PC (not even the anti-virus). I was not doing anything during the writing process, in fact I was having a breakfast. It wrote the DVD with 12 buffer underruns. And its final writing speed was 6x, probably a speed reducion measure because of those buffer underruns. Shocked by that outcome, I wrote another identical DVD, but using ImgBurn, also at 8x. This time I was cleaning the table & the dishes from the breakfast. ImgBurn also "finished" at 6x, but it did not report any buffer underruns. By the way, PowerRec is ON and AutoStrategy is AUTO both in PlexTools and in ImgBurn. ---------- Now, the question which I am asking is - does ImgBurn report occurences of buffer underruns? If it does, does it also report a LBA sector at which every buffer underrun occured? And a final question - why there were no buffer underruns reported in ImgBurn, while the writing process was performed similiarly (started at 8x, finished at 6x) as in PlexTools which had 12 of them? P.S.: The DVD writer is on a separate ATA channel than the drive from which the source data was read. The content which I was writing was an image file of 4.2 GB (not thousands of small files, which in general case can be the cause of buffer underruns, since the HDD might not be able to "collect" all of them in time).
  6. Blutach, I merely suggested that checkboxes "Verify" and "Test mode" should have short and meaningfull pop-up descriptions, because most other elements in ImgBurn do have them (some of those descriptions are useful, some are just dummy...etc.). I did not do this for my sake or sake of any expert here, but for the sake of a typical user. And I just took the opportunity of suggesting that to clarify my uncertainity if the verification is a true comparision or just a readability check.
  7. Your statement is correct, because this time I waited a bit longer when it hanged, and after some time it completed the media inquiry. Now I know that I only need to wait a bit. Maybe you should incprporate some notice saying "this may take up to a minute, please wait", which would be displayed whenever ImgBurn is inquirying the drive.
  8. Thank you for clearing my doubts about the Verify option. I suggest that short pop-up descriptions should be added for these two elements. As an example, the Verify description could be "performs bit-by-bit comparision of the source and written content", and for "Test mode" it could be "simulates the whole writing process by doing everything except using the laser itself". Maybe they are not the best ones, but they make a start.
  9. I've just downloaded and installed ImgBurn I started it (the bad disc was already in the drive). Then I switched to the "Read" mode, and ImgBurn started to acquire the disc info. It jammed at "Getting media status...". The "Mode menu" was greyed (unavailable) and no key or key combo could "rescue" me (I tried ESC, CTRL+ALT+W/B/D/V, F5, etc). The only key combo which worked was ALT+F4, which terminated the interface thread ans closed ImgBurn "nicely". In this kind of situation, I would like to be able to press ESC (for example) and that should immediately cancel the current operation and "kick" me back to the last state which was OK (in this case, probably the one in which ImgBurn was before I commanded it to switch to "Read" mode).
  10. Oh, silly me! I'm still using ImgBurn, and I was sure that I updated it to I did that at several other machines, but apparently not on my own . Hit me at will. P.S.: So, you are saying that ImgBurn does not jam any more or what? I'm not sure what you meant when you said "hasn't done that".
  11. Hello, Sometimes I happen to insert a rather badly written optical disc (usually DVD) in my drive (it is a Plextor PX-755A, not some junk), and when I start ImgBurn, it tries to get some info from the medium (for example, if I switch to the "Read" operational mode, it tries to read the first 2000 sectors or so...). The problem with this is that, if the media is faulty, the drive just whines in despair while trying to read it (spin-up-down etc.), and ImgBurn jams because it is insisting on that data. Fortunately, the architecture of ImgBurn is robust (credit to the author's engineering skills), so it (as I have noticed) has a separate thread for working with the drive. That leaves the interface un-jammed, so I am able to exit ImgBurn in these situations (it terminates the interface thread and exits). BUT I would like to be able to abort the work of the interface thread at any time, without exiting ImgBurn. In another words, if ImgBurn tries to read something from the disc, I want to abort it and do something else. For example, I want to erase the disc, but I can't initiate that operation because the drive is already stuck because ImgBurn is requesting info from it. The final question is: is there some key or key-combo which cancels the job of the interface thread? If not, PLEASE add in ImgBurn as soon as possible.
  12. Hello, I have noticed that checkboxes "Test mode" and "Verify" (which are present in "Build" and "Write" operational modes) do not have pop-up descriptions. They may seem unecessary for advanced users, as these two terms are mostly self-explanatory for them. But there are a lot of people who do not have much experience with optical discs, so they are not so sure what those options mean. And, even I, who am an expert user, am not sure what does the "Verify" checkbox do. Does it perform a bit-by-bit comparision of the content on the freshly written media, with the content on the hard drive? Or does it merely read the content of the freshly written media, just to ensure that the media is fully readable (doing no comparision)?
  13. First of all, thank you very much for your commitment to retain compatibility with legacy operating systems. That means a LOT to some people! Secondly, I have some very good news. After downloading your MSIMG32.DLL, I realised that my MSIMG32.DLL was faulty! After trying your version, good things began to happen . I tried ImgBurn on a "bare" Windows NT 4.0, with NOTHING installed except Service Pack 6a. ImgBurn of course complained about missing MSIMG32.DLL. After providing it in \WINNT\System32\, ImgBurn worked just fine! No lousy Internet Explorer was needed at all (and that is the prime goal). I consider this case to be solved! This is an example why it is good to participate in forums . Now I have to re-test some other programs which previously used to crash because of my faulty DLL . I highly recommend you to place a notice on some visible place (perhaps a download page) on ImgBurn web site, which would say that Windows NT 4.0 users need to have MSIMG32.DLL in their \Winnt\System32\ folder, and please give them a direct link to download it. - All the best, Bosanek
  14. Hello, first to say the inevitable - ImgBurn is one of the best optical-drive-related programs by my criteria. I appreciate small, efficient, compact, non-bloated (in graphical sense), well organised, professional-grade (in usability sense) applications. ImgBurn is very good to excellent in all of these criteria. But I appreciate an application as twice as I would if it also works on Windows NT 4.0 (and preferably on Windows 95). ImgBurn formally supports them. BUT I tried ImgBurn v2.3.2.0 on two computers running Windows NT 4.0 Workstation (SP6a+ applied, one PC has Internet Explorer 5.5 installed, the other has not). ImgBurn installs just fine, but it can not load. The problem is a VERY common incompatibility which plagues many new applications on Windows NT 4.0. They use some newer GDI functions, which are natively present only in Windows 2000/XP (and newer). AFAIK, there is no update for Windows NT 4.0 to bring those GDI functions. A paradox is that many programmers are not even aware that they are implicitly using those functions, so their applications are unnecessarily incompatible with legacy O.S.-es. OK, this is what happened: When I tried to run ImgBurn, I got a fatal error about missing MSIMG32.DLL: Then I transferred this file from a Windows 2000 PC (it was in \WINNT\System32\) into my \WINNT\System32\, and started the program again. This time I got another error (which I expected to happen from my experience with other programs which had the same incompatibility): P.S.: Those two screenshots "belong" to another application which had exactly the same problem (which I reported on its forum), so I just reused them for this occasion. To remedy this issue, a programmer has to clense his code of newer API calls (specific to Windows 2K/XP). If you need help with testing, I can help (I have a VMware virtual machine running Windows NT 4.0).
  • Create New...

Important Information

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