JohnnyBob
-
Posts
29 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by JohnnyBob
-
-
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!
-
I'm not sure what you mean by "the box on right"...
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-RDisc Information:Status: IncompleteState of Last Session: EmptyErasable: NoSessions: 2Sectors: 61,111Size: 125,155,328 bytesTime: 13:36:61 (MM:SS:FF)Free Sectors: 287,334Free Space: 588,460,032 bytesFree Time: 63:53:09 (MM:SS:FF)Next Writable Address: 72513Supported Write Speeds: 16x, 24x, 32x, 40x, 48xTOC 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: 97m17s06fManufacturer: Moser Baer IndiaStart Time of LeadIn: 97m17s06fLast Possible Start Time of LeadOut: 79m59s74fPerformance (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"...
-
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?
-
As usual, you can download it and view the changelog by visiting the main website.
Special 'Thanks' to all the beta testers, translators and donors!
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...
-
Ahh oops, it seems I rar'd up the non upx'd version.
This one is back to ~210k again
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.
-
I thought the ImgBurn one had always been about 200k?
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...
-
I had a go at speeding up the '<' button response times by performing less reverse seeks and more sequential reads.
It's quite noticable when previewing from slow media - i.e. direct from an optical drive.
The real reason for the delay is that when you press those <<, <, >, >> buttons and the video is playing, the program defaults to playing all the buffered data (note: this is nothing to do with my recently added 64k read buffer - which is now 32k btw). I've told it not to do that now so you should find it's much better.
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.
-
Ok, try this one...
(attachment removed)
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.
-
Ok, here's 1.1.3.0.
I had a little look at why it might be moving and I think it's because the window is initialised in the top left corner of the screen and then gets moved later on. I've tried to move it sooner now but as I never noticed the problem in the first place I don't know if it'll be any better or not!
This one also includes a 64k read buffer so it should play ok from optical drives now.
I also made the info window default to snapping to the top left corner of the main window rather than popping up at 400 x 400!
(attachment removed)
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.
-
Ok, here's another one based on the code I got from jeanl lastnight.
(attachment removed)
I tested it with the LBs from a half-dozen long movies. Alas it doesn't have any effect. My *glitch* remains.
I burned several DL discs overnight and tried to ignore *glitch*, but found it too disorienting. So at this point disabling DD overlay seems best.
FWIW, maybe irrelevant, I found some trialware that will capture ActiveX graphics onscreen: ACA Capture Pro. In other words, it works with the DD overlay active. However it won't capture my *glitch*. It ignores it, even when the capture hotkey is clearly pressed while *glitch* is onscreen. Instead, it captures the bottom image in my duo-graphic above. So it's as if *glitch* doesn't exist.
-
Thanks for your continued interest. It sounds like you don't understand when my *glitch* happens. Sorry. I'll try to explain it again. The following are true statements, as precisely as I know how to word them, and will hopefully clarify everything...
(1) The above *glitch* as depicted in my graphic only happens when I press the Preview Selected Cell button.
(2) I do not see it at any other time.
(3) It only happens once.
(4) It does not happen again unless I press the Preview Selected Cell button again.
(5) If I use the slider bar or VCR controls (<< < > >>) followed by the Play button, the *glitch* does NOT appear.
Did I clarify it?
-
-
That's probably just directshow's doing?
Try turning the 'don't use overlays' option on in the setting and see if that's any better.
As I mentioned previously, I'm stepping though this frame by frame in the capture and what you're describing isn't happening here. It sounds like it should be really obvious but it isn't to me.
Yes, it appears to be a DirectX phenomenon. If I check that box in Irfanview settings as you suggest, it replaces the *glitch* with a black screen for the first 0.5 second, after which everything is normal. I can accomplish the same thing by disabling DirectDraw Acceleration using the C:\WINDOWS\system32\dxdiag.exe system utility. I'm running DirectX Version 9.0c (4.09.000.0904). I'll check to see if my 5-year-old computer can handle an update.
Note that I've revised my estimate of the duration of the *glitch* from 1/5th second to 0.5 second. This is due to introduction of a trusty stopwatch ordinarily used to time sporting events such as the 100 meter dash (or 100 yard dash on this side of the Atlantic). After repeated tries, it's fairly clearly 0.5 second (plus or minus 0.1 second), or fairly close thereto.
I've been frustrated in my attempts to capture the preview screen during the *glitch*, or indeed at any time. I can only get a black box with utilities such as Irfanview and Gadwin's PrintScreen, perhaps another peculiarity of my 5-year-old computer which has no separate video card (only shared memory)(?). The BMP button on the ImgBurn preview screen works fine to save a BMP, but I'm not quick enough to hit it with my mouse during the 0.5 second that the *glitch* is onscreen at the start. I wonder if there's a keyboard equivalent to pressing that BMP button?
blutach: Sorry, no offense intended. I was trained as a scientist so am simply making impartial observations, as I see it.
-
I made a little change to the combobox code that'll hopefully stop it drawing itself over the screen when you click play.
That fixes the pixelation I was seeing during the preview playbacks. No more little white/light-colored boxes in the video! Thanks.
However the *glitch* still happens, for me... For the first 1/5th second (approximately) after pressing the Preview Selected Cell button, the video is frozen and shifted towards the upper left. Approximately 80-90% of the screen is black, with just the upper left portion showing a partial video. Then it centers itself to occupy the entire screen, plays smoothly thereafter, and does not reappear if I rewind the film with the < control or use the slider.
I tried about 6-8 long movies that require a LB, involving 20-30 total LB tests, and my observations were the same. They all showed the initial *glitch* as described above.
The audio works correctly during the previews, most of the time. There was one instance where it was mute during playback after a rewind with the < control. But on subsequent tries, it worked OK with that cell too. So that was a temporary error of some kind. It works OK 95%+ of the time.
I judge that I can now use the 2.4.1.0 installation with your latest preview file. Since I know what is happening and what to expect, the *glitch* can be ignored. Of course I won't know for some time whether this somehow affects burning/playback of the DL discs at the layer break, i.e. my confidence is somewhat lowered by the *glitch*. I always prefer perfection.
weisborg & blutach: Again (see prior posts in this thread) it does not work to drop the 2.4.0.0 previewer into the 2.4.1.0 installation. The 2.4.1.0 system refuses to accept it, giving an error message when a LB preview is attempted.
-
Using the 2.4.1.0 installation with your new version of ImgBurnPreview.exe (v1.1.2.0, from your attached .rar file):
(1) run ImgBurn
(2) click "Write files/folders to disc"
(3) check the Auto box in lower right corner
(4) browse and select a long movie on my hard drive that will require a layer break
(5) a list of possible layer breaks is automatically displayed
(6) click to select one of the layer breaks then click the Preview Selected Cell button
(7) just as the video begins to play, the *glitch* happens immediately, for perhaps 1/5th second something strange shows in the preview window
(8) then if I use the < key control to scroll backwards to a point before the layer break, then press the Play button, the *glitch* does not reappear.
I've done this a lot of times with different movies. I'm pretty sure now that the *glitch* is the correct video but it's frozen for perhaps 1/5th second at the outset, and shifted upwards and to the left in the preview window. For example a table lamp which should normally appear in the lower right of the screen, appears near the top left of the screen during the *glitch*. Then the video centers itself properly and plays normally from that point, except... Some small white or light-colored boxes appear occasionally in the video during the playback, which I interpret as pixelation.
I tried with Irfanview but it won't capture anything on my screen from the video. All I get is a black box. Sorry I'm not familiar with any other graphics software to do that sort of thing.
To satisfy Cynthia's curiosity, checking the "Don't Enable Sound" settings box has no effect. Same things happen. However I will note that 2.4.1.0 is the first version where I've heard any sound in the LB previews, prior versions were mute.
blutach's comment about starting on a B frame and improper decoding is beyond my knowledge. I'll just note that this glitch happens with all of the movies I've tested (about a half dozen). It only happens in ImgBurn 2.4.1.0, not in 2.4.0.0 nor prior versions of ImgBurn that I've used in the past.
Now I must bid you all a good night. Maybe tomorrow... Thanks for responding.
-
jeanl gave me the fix so please try this one... (after reinstalling 2.4.1.0 of course)
(attachment removed)
Your new version of ImgBurnPreview.exe (from the attached .rar file) fixes the freeze/stop, so that it is possible to scroll in reverse past the LB using the < control. However something is still wrong. There is pixelation and a strange shift of the video at the start of the preview, from the upper left towards the middle of the preview window. I tried this with several different long movies (7GB+) that are stored on my hard drive with the same result.
I also tried mmalves' suggestion to use 2.4.0.0 ImgBurnPreview.exe with the 2.4.1.0 installation, but that is refused. When I attempt to Preview Selected Cell is says: "You need a newer version of ImgBurnPreview to use this feature. Version Required: 1.1.1.0+. Version Installed: 1.0.2.0. Please visit http://www.imgburn.com/ to get the latest version. OK"
So at this point the 2.4.0.0 installation is still the only one that works right with the preview LB feature.
-
I would think the fixes in the actual program far outweigh that you can't rewind by pressing a button in a 3rd party tool?!
What's wrong with using the slider?
Thanks, but no thanks. I've been using the < preview control since I first started using ImgBurn. It scrolls smoothly (or did, in prior versions) past the layer break in the reverse direction. Then upon playback I can see exactly which prior scene will be used for the LB. Nothing else is quite as satisfactory. The << jumps too far in reverse, and I can't remember exactly where the LB starts. I've never used the slider bar, which would probably also be imprecise. This outweighs everything else, for me. At least half of my burns are to DL media, so it's very important to me.
-
Thanks for the info. I've reverted to 2.4.0.0 and will stick with it til this is fixed.
-
Yes.
What do you mean with this:
but then the playback is apparently incorrectThere's something strange about the 2.4.1.0 LB preview playbacks. After going to a position prior to the LB using >> (because > doesn't work), some image-sequences (video images or clips maybe only 1/10th second long) appear in the playback that are not supposed to be there, and/or some are absent that are supposed to be there. It's as if a bit of scrambling has happened, foreign images inserted where they're not supposed to be (obviously out of place). This becomes particularly apparent when compared with 2.4.0.0 which offers the same LBs, and plays their previews back correctly and smoothly, as did prior versions of ImgBurn.
Please Ditch Open Candy
in ImgBurn Suggestions
Posted
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.