JohnnyBob

No. I installed ImgBurn on this box a year or more ago and wasn't aware of adware. Then I ran those softwares a couple of months ago, found opencandy, and removed it. I put 2+2 together. Seems a reasonable hypothesis.

I recently did complete scans with Malwarebytes and Superantispyware and one of them found your opencandy junk and removed it OK. Maybe that's easiest.

Ditto. Open Candy is getting very major negative vibes recently. Even some antimalware such as avira is blocking is as a virus. People are unhappy. https://en.wikipedia.org/wiki/OpenCandy (I just edited to Wiki to include a few helpful references, but still think you should dump it!)

The opencandy.com website suggests these ways to avoid their crappy software, which are unfortunately bundled with the ImgBurn installer: Beginner: disconnect your internet connection (beware some software needs the internet to complete its install) Intermediate: run the OpenCandy powered installer from the command-line with /NOCANDY Advanced: add a domain block in your firewall for *.opencandy.com However, I never see their offers, perhaps because the relevant domains are blocked in my MVPS HOSTS file. Be careful out there, children. It's a real jungle!

This bit : My ImgBurn doesn't look like yours. Where are your tabs at top on the right? I'm in Build mode with Source being D:\ my optical drive which contains the CD original to be converted into an .iso file. My output is Image to a disk file: K:\KevinMRI\KEVIN_MRI.ISO With those selections there is no set of data to be copied such as you have circled. If I switch to Device output then I see a Device tab on right with a window containing info such as you have circled, and it contains the following: ATAPI iHAP322 9 6L1H (ATA) Current Profile: CD-R Disc Information: Status: Incomplete State of Last Session: Empty Erasable: No Sessions: 2 Sectors: 61,111 Size: 125,155,328 bytes Time: 13:36:61 (MM:SS:FF) Free Sectors: 287,334 Free Space: 588,460,032 bytes Free Time: 63:53:09 (MM:SS:FF) Next Writable Address: 72513 Supported Write Speeds: 16x, 24x, 32x, 40x, 48x TOC Information: Session 1... (LBA: 0 / 00:02:00) -> Track 01 (Mode 2, Form 1, LBA: 0 / 00:02:00) -> LeadOut (LBA: 61113 / 13:36:63) ATIP Information: Disc ID: 97m17s06f Manufacturer: Moser Baer India Start Time of LeadIn: 97m17s06f Last Possible Start Time of LeadOut: 79m59s74f Performance (Write Speed): Descriptor 1... -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00 -> EL: 359848 (0x00057DA8) -> RS: 2,823 KB/s (16x) - WS: 2,823 KB/s (16x) Descriptor 2... -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00 -> EL: 359848 (0x00057DA8) -> RS: 2,823 KB/s (16x) - WS: 4,234 KB/s (24x) Descriptor 3... -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00 -> EL: 359848 (0x00057DA8) -> RS: 2,823 KB/s (16x) - WS: 5,645 KB/s (32x) Descriptor 4... -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00 -> EL: 359848 (0x00057DA8) -> RS: 2,823 KB/s (16x) - WS: 7,057 KB/s (40x) Descriptor 5... -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00 -> EL: 359848 (0x00057DA8) -> RS: 2,823 KB/s (16x) - WS: 8,468 KB/s (48x) However, as I said, I am not using Device output. I'm outputting the .iso file to an Image file on hard drive. Is that sufficient info...?

Thanks. Here's what seems to be a relevant part of the huge .log file (attached). I'm not sure what you mean by "the box on right"... ImgBurn1.log

Thanks for the info! Yes, I'm using the latest version of ImgBurn = 2.5.6.0 Why is it a problem? Because I want the usual .iso format. I'm familiar with .iso as are most people. I never heard of .bin/.cue. Also I don't want 2 files where 1 should do. Using the Build mode, I got the .iso file made OK, but it comes along with a .mds file. Why? Also, the resulting image won't verify, producing all kinds of errors. Why?

I'm trying to make an .iso image file of a MRI (Magnetic Resonance Image) CD using ImgBurn. MRI is used in hospitals to take pictures inside the body. I've done this in the past with prior versions of ImgBurn and got an .iso file OK. Now I'm getting two files: .bin and .cue. Why? How do I get a normal .iso image file instead? I don't see any relevant settings in ImgBurn offhand.

It used to, but quit after I recently reinstalled my op system and ImgBurn. I guess I may not have a setting right somewhere. My usual procedure is to burn a disc (Write files/folders to disc) including an automatic verify thereafter, then I want it to eject the finished product. It cycles the tray after burning, before the verify, so it recogized the drive OK. Why won't it eject the tray after the verify? I note that there is no eject option on the Settings > Verify tab. However on the Device tab, there are checkboxes to eject after a Read, Write, Verify, or Erase operation, and I have the Verify box checked there. What/where else would the proper setting be located?

Thanks for the new version. I was a bit surprised to receive the email notification telling me I had a private message from administrator: jurdreda has sent you a new personal message titled "From Administrator". You can read this personal message by following the link below: which led me to a suggestion that I somehow belonged to a banned group, and then to a website selling Viagra at a discount from Canada. I presume that was a joke because I don't think it would do me much good! Cheerio...

I seems to work exactly the same as the bigger version, except perhaps the black horizontal lines through the video (whenever there is motion) are more pronounced.

Even with the bigger ImgBurnPreview.exe (468 KB vs the original 209 KB), the entire ImgBurn installation folder in windows is only 2.16 MB total. That's an amazingly efficient coding and design IMHO! So I don't believe it's important, unless perhaps as an indicator of a possible compiler problem - but Blutach negates that with the info that Linux was included in the latest version. Well, I don't really know, but am just trying to summarize...

Yes, that improves the responsiveness of the control buttons and operations considerably, which is now "good enough" in my opinion. However there is now a slight rewind at the beginning of the preview. It's only noticable if it begins with a scene that has fast action. The motion is reversed (rewound) very briefly, for perhaps 0.1 second, then continues forward normally. This could be interpreted as a brief freeze if the beginning scene has no fast action. Perhaps that was the case in prior version(s) and I didn't notice it(?). The black horizontal lines remain, especially noticable on white/light color objects/images, which have jagged edges when they're in motion. You interpreted this as possibly an interlacing effect. Charlie Chan say: Remember ancient zen teaching to leave a little imperfection lest the gods get jealous.

I agree with blutach. The < bug has been fixed. I tested it fairly extensively. It's OK now. I can use this latest version reasonably OK to select layer breaks, with only minor quibbles remaining... There's still a short freeze of the video at the beginning of the preview, after pressing the Preview Selected Cell button. I don't think it's as long as 0.5 seconds anymore. It's now shorter, maybe 0.1-0.2 seconds, but still noticable. Things are a bit sluggish, in general. Like after pressing the Preview Selected Cell button, there's a 1 second-or-so delay before it takes effect and the preview begins playing. Then if a control such as << or < is pressed, there's also a 1 second-or-so delay before it takes effect. But there's no delay with repeated presses of a control button. The preview video is a bit streaky, with horizontal black lines, when motion is involved. This might be a compression artifact, as if it's being over-compressed. It's still quite legible, just not very pretty. I'm getting happier with this, and could settle for it.

Re your new ImgBurnPreview.exe 1.1.3.0 version, I've now tested several layer breaks in assorted movies on my hard drive... My "glitch" is partly fixed. There is no longer a shift from the top left quadrant to the whole preview window. The preview opens and plays entirely in the whole preview window, start to end, after rewinds, etc. There is still a 0.5 seconds (approximate) freeze of the video at the start, right after the Preview Selected Cell button is first pressed. If that freeze is by design (intended), personally I would prefer that it be removed. ---------------- However a new bug is introduced... The < button (Rewind 1 video frame) is associated with a new bug. The other controls in the preview window (<<, >, >>, slider bar, etc) do not have this bug associated with them. After clicking the < button (one or more times), followed by the Play button, there is a fatal freeze of the preview window. All controls become inactive, the video stops and won't play, etc, nothing works. To escape the freeze, I must click the 'x' (Close) button at the top right of the preview window. That brings up the attached error message graphic. Selecting End Now closes the preview window, and everything behaves normally thereafter. ---------------- I also noticed something else, I think, but it needs further research... I thought the << Fast Rewind button was supposed to rewind 10 seconds. It doesn't, if pressed immediately after the Preview Selected Cell button. In that case it goes back to the layer break position, where the preview first started playing. Thereafter and in general the << button may indeed rewind by 10 seconds. ---------------- My other observation [which might not be relevant(?)] is that ImgBurn.exe and ImgBurnPreview.exe are using Normal process priority. I'm surprised, and thought AboveNormal priority (at least) would be used.