LIGHTNING UK!

That doesn't really help though because your machine should be able to decode MP3's without that. I'd still like to checkout the file to figure out what stops the normal DirectShow filters and ACM from working. I promise I'll delete it again when I'm done looking into the problem.

You'll have to upload it / send it to me then so I can figure out the problem. Being able to play it doesn't mean much though, you need to be able to open it in GraphEdit - and I expect that'll fail.

I'm guessing that BRG-90-20.mp3 file is messed up in some way then.

post a log

Read the pink thing at the top of the forum and post a log.

You can't reorder tracks in a single larger bin/wav file, there's no 'end of track' marker and the 'INDEX's must be in order. They're need to use another tool to split the large bin/wav into smaller ones based on the original cue file and then load those files as they would any other mp3/wma/small wav etc. It might be easier to just mount the CUE in DT and rip the tracks again. The error message you mentioned earlier doesn't exist in my code so I can't help you with that until you can provide the real one. Nothing jumps out at me as being *wrong* in the posted cue. If the files don't actually exist on your hdd then that could indeed be the problem.

What does your merged file look like? You can easily just make a CUE with offsets by reading an audio disc within ImgBurn.

Have you tried the DVD+R Verbs? I prefer those to their DVD-R.

What controller is the drive connected to? Have you tried burning at 8x, 12x etc?

Unless it's using the MCC or TY dye, I don't consider it 'decent' I'm afraid. Try cleaning the lense on your laptop drive, they're not exactly well designed and it's easy for it to get dirty.

The drive is having trouble burning to that media. Update your firmware. http://www.sonynec-optiarc.eu/en/support-s...-ad-series.html

Check with your laptop manufacturer to see if there are any firmware updates available for your drive. Being 'Sony' discs doesn't really mean anything, you need to pay attention to the dye they use - in your case that's 'OPTODISCW004'. Your drive must have a problem burning them as it's unable to read back what it just wrote. Get yourself some decent *write once* (i.e. not rewritable!) discs made by Verbatim or Taiyo Yuden and you should be ok.

Please see post 28 in this thread.

Use the 'drop' window.

Use DVD+R DL, NOT DVD-R DL.

It's impossible to say until you've tried a few different discs (with different dyes / MID's). If none of them work then it's probably the player. If some discs work and some don't then it's probably the discs (and a little bit of the player in that it doesn't support many dyes / MID's)

I'm sure it just wants the best quality burn possible. A drive might achieve that at 4x or it might do it at 16x (or something inbetween!).

http://forum.imgburn.com/index.php?showtopic=8000

Your drive complained that it couldn't write to the disc. Try burning at a faster speed, your drive will probably do a better job and burn quality will actually increase. 8x or 12x should be fine.

Your disc in the above example is actually just over 128MB in size so it wouldn't fit in the buffer. Increase the buffer to 140 and it will. My guess is that you then won't see the prompt about directshow not returning data (and that's because the problem won't occur, not that it would just hide it). Can I just check that if you mix the songs up in the CUE (i.e. change the order to 3, 1, 2) that with a 128mb buffer it's still the last track that gets the error? My guess is that whichever song the buffer size lines up with is the one that produces the error message. Re. Successful Verification: Due to drives reading and writing CD-DA sectors with an offset (i.e. it doesn't write the data I give it exactly where I tell it to - and every drive is different), it's not possible for ImgBurn to do a byte level comparison on that data type. ImgBurn will just be checking the sectors are readable - which they are The option to make ImgBurn do a byte level comparison on CDDA tracks can be found in the settings - but as it only works for drives where the read/write offset cancel each other out exactly, I don't recommend you change it. It would just make verify mode complain about millions of 'mismatches' on all other drives.

No, you got the 8x verbs. Get the proper 2.4x ones with the MKM-001-00 dye. Notice yours are MKM-003-00.

'Continue' is the same as 'Ignore', which basically means ImgBurn will be zero filling (digital silence) the remaining 1MB of that file. Do you notice that when it's doing the initial 'analysing' pass (right after you've clicked the write button) that it hangs for a while? I don't see why that stage would work ok and not the real decode pass. Expect a PM from me.

Ideally your machine should be using NTFS, not FAT or FAT32.

Ah, I found the problem... it's not just x64 OS's that it happens on For some reason the directshow filter opens the file for read + write access and that causes some of my code to fail because it's only allowing for programs to open the file with read access - well, I don't want them writing to the file whilst I'm using it! The changes I've made to get this working were actually the same as I did a couple of days ago for another bit as a result of my learning something new about the inner workings of the 'CreateFile' API function. So basically you'll have to wait for 2.4.3.0 to burn APE files when using the radlight filter

Is the drive connected directly to a motherboard mounted USB port? (i.e. not off a backplate cable or via a USB hub) Some USB controllers just don't like certain external enclosures. I doubt there's much you can do besides change it for a different one. The problem dates back a good few years now (with all burning software) and I'm not sure anyone really found the reason for the I/O commands to fail like that.