@Kenny Duffus: you would be right, in case k3b would reject the cue file when loading it (see my comment of 2006-12-15 20:42:50). But it doesn't give an error, complain, or even notify the user at that time. Instead, working around this problem was purposely implemented as a feature in k3b [*].
From the user perspective all is well, until the user initiates the burning process which will always fail because k3b sends the cue file unmodified to cdrecord/cdrdao. Either refuse the cue file at the start (or at least warn/inform the user), or make sure the workaround actually works completely (so that the user can successfully burn the image).
@Kenny Duffus: you would be right, in case k3b would reject the cue file when loading it (see my comment of 2006-12-15 20:42:50). But it doesn't give an error, complain, or even notify the user at that time. Instead, working around this problem was purposely implemented as a feature in k3b [*].
From the user perspective all is well, until the user initiates the burning process which will always fail because k3b sends the cue file unmodified to cdrecord/cdrdao. Either refuse the cue file at the start (or at least warn/inform the user), or make sure the workaround actually works completely (so that the user can successfully burn the image).
[*] See: http:// bugs.kde. org/show_ bug.cgi? id=115755 bugs.kde. org/show_ bug.cgi? id=136600
as well as (comment #2 on) http://