LIGHTNING UK!

That's all I wanted to see If you then load the disc back up in Read mode and hit the 'Media Information' button, does it not show the CD-TEXT info?

It does bit by bit, that's how it knows to display the 'miscompare' box when the data in the current sector doesn't match.

The pregap for the first track isn't added on purpose... why would you ever want an additional one at the very start of the disc? There's already the fixed 2 second one. Gaps go between the tracks, and being the first one, it wouldn't really be right to add the same pregap to it that all the others have. You can make date + audio discs with the 'Create CD CUE File' window, or even audio + data (as in CD-Extra) with it - but that isn't the easiest thing in the world! I use it a lot when testing other functions within ImgBurn. It allows me to make discs that are totally random in the hope that the Read/Write modes can cope with them!

Are you talking about when it plays from the VERY beginning or just if you stop + start it anywhere? I don't know if it's possible to get a screenshot / video of what you're seeing but it might help.

The CD-TEXT comes from the CUE file itself, not the audio files. It's therefore a little odd that you're not getting it. Can you provide a log of the burn?

Does winamp read cd-text? That's the only place it could get the names from on a cd. Shame about the graphedit thing, I was hoping the filter would have a properties page showing a nice 'about' type bit of info. The one I played around with earlier seemed to have one, I think that was madFlac though.

jeanl gave me the fix so please try this one... (after reinstalling 2.4.1.0 of course) (attachment removed)

at this point... give up! If it's at 99% and all you're getting is read errors, just cancel it and then don't delete the image when it prompts. You'll have most of what was on the disc.

That's tricky with flac files actually, I was hoping you'd just know! If you didn't install one especially, it must be part of some bigger filters collection. If you open the file in graphedit and right click on the source box to bring up properties, you might get a clue that way.

Nothing much I can do about this, it comes down to how directshow decodes it. Play it in GraphEdit and you'll probably find it does the same thing - just outputs no sound.

It's a brand (dye) specific problem with your drive, the software you use doesn't even come into it. Check for firmware updates for the drive.

Any chance you can get the 2.4x Verbatim discs? They use the MKM-001-00 dye rather than MKM-003-00.

Are you getting the 'Write Error' error each time? Have you tried burning at anything other than 2x?

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?

The session level options DO modify all the tracks. That screen is not just for audio, its for creating CUE files in general. That's where the option to add sessions comes in. Of course the 'Label' stuff displayed in the GUI is totally made up for Audio CD's. When available, I base it on the disc's CD-TEXT info (that's at Disc level, not from the Tracks). Otherwise it'll display the default 'Unknown' text.

You might be ok if you use this filter: http://www.dsp-worx.de/?n=15 Do you happen to know/remember which one you're currently using? I've just done some testing with various filters, comparing their output to the original files. I used the 14 tracks from the 'Semisonic - All About Chemistry' CD for testing. Using the madFlac v1.7 filter, none of the tracks came out 100% (bit perfect) like the originals - I've let the author know. The illiminable v0.71.0946 filters had pretty much the same problem. Only tracks 7 and 8 were identical to the originals. The illiminable v0.73.1936 filters failed in the same way the v0.71.0946 did. Only tracks 7 and 8 were identical to the originals. The DC-Bass Source v1.11 filters produced files that were all 100% like the originals. I also tested Flac.exe v1.2.1 (just for reference), all the files it produced were 100% like the originals.

SPLIP is Seamless Playback Linked in PCI. It's a flag in the IFO files that's commonly associated with the layer break position. Typically, the cell just after the layerbreak is marked as non-seamless (so SPLIP = No). If you select a cell that's marked as SPLIP = Yes, the program will change that cell's flag to 'No' (unless you also have the 'Seamless' option enabled). All the options provided are 'safe', the ones with better ratings are just good starting points if you're going to preview all of them - leave the 'average' ones until last. To find out if your player supports the seamless option or not, you just have to burn a disc and try it!

The only reason the 'Good' one is marked as 'Good' is because of the SPLIP flag being set to false. Without it, it's 'Average' too. So basically, if the next available position looks better to you in the previewer, use it That said, the screenshot looks like it's fading out there - it would be more of a problem in the middle of a fast action scene!

It only needs 2 read errors (in a row) to bomb out of the 'getting media status' code. If you really do have problems there then the file system is probably corrupt too, hence the disc would be useless.

ImgBurn hasn't done that since 2.4.0.0 came out.

An image is an image, doesn't really matter what it's for. You can follow the 'How to burn an image file in ImgBurn' guide in the Guides section.

Every time you click 'Continue' it moves onto the next sector. So it IS getting around it, you just have lots of errors in a row. Keep clicking Continue until it's finished. If you like, change the default number of software retries to make it faster. Set it to 2 or something.

Or just tick the appropriate box on the Advanced -> Restrictions -> ISO9660 tab.

Click Ignore / Continue?

Ok I see the problem now... It's where EAC adds gaps to the end of the previous file, but after doing a dummy decode pass on the file to get an accurate duration, it's not actually producing enough data for the 'INDEX 0' points - i.e. they're beyond the end of the file. I can work around it by ditching the trailing index 0 point if they're beyond the end of the file like that but obviously that's not ideal. I'd love to know why the directshow filters aren't outputting enough data... or perhaps where I'm not quite getting how it should work!