LIGHTNING UK!

Is the drive just reporting that weird LTSA for that disc when those drive features are activated? So put them back to their default values and check the disc info again (eject + reinsert the disc before looking). I want to work out if it's messing up when burning or when reading. The iHAS122W uses a non Mediatek chipset I believe - it's more of an Optiarc drive than a traditional LiteOn one. 'unusual information'... I'm intrigued, PM away.

It doesn't matter how many times you say it, there's still no 'data' on a proper Audio CD besides CD-TEXT... and I know that as so few discs use it, your hardware must have an offline database of some sort if it's showing track names for the commercial discs you're putting in it. The 'Disc ID' probably gets generated from a calculation based on the number of tracks on the disc and the length of each track. Then it's just a case of looking that calculated 'Disc ID' up in the database and showing the names associated with each track. Obviously that can't work homemade discs - unless you program the data into the database. The actual topic is here is why your devices can't read CD-TEXT properly if ImgBurn can and the WMPCDText plugin can. When I custom make a CD and add my own CD-TEXT, both ImgBurn and WMP (with the aid of WMPCDText) display all of the correct disc / track info - including the Album artist. I tried it on an old Pioneer DVD/Video combo player that clearly shows it's reading the CD-TEXT on the disc and the Album Artist shows up on that just fine too. Do you not get any 'artist' info at all - either at disc level or track level? The album name and track names are stored in '0x80' packs within the CD-TEXT info. The album artist and track artists are stored in '0x81' packs within the CD-TEXT info. If you aren't getting anything from the '0x81' packs then I'd just put that down to a bad CD-TEXT implementation in your hardware. Something I did find funny when looking at this stuff is that my PS3 and newer Sony BD player both lack support for reading CD-TEXT... and yet CD-TEXT is something Sony came up with! Anyway, I'm happy with my imeplementation of CD-TEXT encoding/decoding. What I generate in code from info in the CUE file (that's then sent as-is to the drive when burning) matches what came from the original pressed/commercial disc in the first place. You can't ask for more than that.

Ok so if it doesn't happen with the drive settings on their default values, the incorrect LTSA (logical track start address) value must be coming from one of those being turned on. This is a firmware bug. If I can reproduce it my end, I may be able to implement some sort of workaround for the problem.

I've no idea, sorry. Search Google and see if someone has already done such a thing - not that I really understand why you'd want such a disc.

Did you ever try burning at 8x? Your drive really shouldn't be having any problems burning to MKM-003-00 at any of the speeds it claims to support - unless the discs you've got aren't up to the normal standards expected of that MID. Sometimes discs manufactured in different countries (with the same MID) perform differently. As your drive failed to close the disc nicely and then failed to read back a few sectors at the end of disc during verification, just check the outer edge of them looks ok - no dust, scratches, finger prints, odd things going on with the dye (colour changes) etc. If your old drive will plug into your new machine (i.e. it's SATA), by all means install that in your PC and continue to use it instead of the new one.

Ah, that info (number) is coming from the drive. You can see it listed in the track information section of the burnt disc. Did you say it doesn't happen when those advanced drive settings are on the default values (just smartburn enabled) ? I assume that's the most recent firmware on the drive?

I have no clue how or why it would be doing that. Can you please go into Read mode and copy + paste the disc info from the box on the right when that disc is in the drive?

You're using an old version of ImgBurn. Try the current release and post a new log if you still have the same issue please.

No offence but it's a waste of time reporting issues in old versions... and that one is 4 years old! Install the current release.

I don't design (or have anything to do with) the offer screens, OpenCandy (and the advertisers I guess) do all that. There isn't a version of the setup program that doesn't use the OpenCandy platform, no.

As it worked in safe mode, it was never going to be firmware related Something is messing with the I/O on your system, it's just a case of finding out what - or ignoring it. Have you tried it with the I/O Interface set to ElbyCDIO rather than SPTI? I'm just curious as to whether or not that I/O Interface would bypass whatever's causing the issue.

I've already asked OpenCandy to give developers the option of making the greyed/disabled 'custom' radio buttons look 'normal' again... it's work in progress.

That depends... are you just wanting to back them up on a disc or do you want to convert them into the proper DVD Video format? You can do the former (just use 'Build' mode - 'Write files/folders to disc'), you can't do the latter. For the latter, convert them using something like DVD Flick or ConvertXtoDVD.

AFAIK, you can still click it (I've edited / updated the guide accordingly).

Yeah the pif levels are a little off around the layerbreak. It's not what I'd class as a spike though, a spike is just a single pixel in width. Maybe clearing opc will help (assuming that log wasn't from after you'd cleared it)... failing that, buy yourself yet another spindle of discs - from a different supplier and see how they go.

You'll continue to get that one warning until such a time as the drive no longer errors out when doing what the program has asked it to do - and unless they update the firmware again, that'll be forever. Hmm I wonder if you'd still get it if you send the payload to the iHAS B drives running the modified firmware? In theory, you shouldn't as I don't recall the C or D drives erroring out like that.

It's probably due to the way ImgBurn locks and dismounts the drive during the burn (you can't access it from Explorer when ImgBurn is busy with it). That doesn't really explain why the OS on your machine isn't kicking back into action and attempting to read the file system on the burnt disc though. One thing I would say... if you haven't already done so, make sure you've closed ImgBurn before putting the disc back in the drive. Ensuring ImgBurn is shut, ejecting the disc, refreshing 'My Computer', inserting the disc again and refreshing 'My Computer' is usually enough to fix problems like this.

Thanks. It's just the first DI unit that has its 'DI' identifier/signature corrupt/missing then... you can see the one at offset 0x0074 is ok.

Maybe this will help you... http://forum.imgburn.com/index.php?showtopic=21970

The 'operating system' ones are read from the OS itself, they aren't technically ImgBurn options. Anyway, they're all still enabled so that's good. Sorry, I don't know why it isn't trying to read the burn disc properly. I don't have that problem here.

ODC probably.

Take a look at the 'Device' tab within ImgBurn's settings and just check the operating system options are all checked.

If it burns and verifies ok, there's nothing more ImgBurn can do. The quality of the burn comes down to the drive/firmware/media combo. If you're getting a spike them maybe clearing the drive's OPC history will help. You can access old logs via the 'Help' menu - and yes, posting one would be helpful (and a kprobe screenshot too).

Just for good measure, clear the drive's OPC history too.

If you opt out correctly, nothing should get installed. All of that stuff is handled by the OpenCandy platform.