Bug#619723: cdrdao extits with .cue:14: Timecode out of range
Tanguy Ortolo, 2011-11-10 23:53 UTC+0100: I imagine that the conditional increment is meant to include the last incomplete frame in the case where a track does not exactly end on a frame. The current implementation is wrong, and it could be corrected by conditionally incrementing len *before* we start computing anything from it; however, given that a frame is only one 75th a second, I think it would be better to simply remove the conditional increment: part of a frame could be lost on the very last track of the disk but I do not think it would matter to anyone. Sorry for the this lot of messages, but that was not exact. I have just read more about the CUE format and what Brasero does; in fact the possible shift would only affect the position of the beginning of each track. When the total length before a given track does not end exactly on a frame it has to be rounded in some way. The current, buggy behaviour of Brasero is to round it to the frame above; the one I am proposing it to round it to the one below; the most accurate one would be to round it to the closest one. But as we are talking about 1/75th of seconds, I still think the simplest solution would be the best one: truncating it to the frame below. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ signature.asc Description: Digital signature
Bug#619723: cdrdao extits with .cue:14: Timecode out of range
As I said, my patch is one approach to solve this problem by dropping the code that adds an extra frame. The other one would be to add that extra frame correctly instead: this solution would be less intrusive to the behaviour of this program but more intrusive to its source code. I can provide another patch for that if needed. I assumed that missing part of a frame is not a real issue, but I do not know this context very well. I think we should ask the upstream authors for advice, since that patch will eventually be merge into their code as it is a general bug fix, and they are likely to know the situation better than I do. Maintainers, do you want to do that by yourselves or would you prefer that I contact them directly, possibly filing a bug report on their BTS and linking it to this one? -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ signature.asc Description: Digital signature
Bug#619723: cdrdao extits with .cue:14: Timecode out of range
Hello.
Alexander Kurtz, 2011-06-14 15:56 UTC+0200:
As you can see, the second track starts at 00:09:75. However, since
there are only 75 frames per second[1], starting at frame #75 is
invalid. The correct start time would be 00:10:00.
I have identified the code which is involved here. It is
plugins/audio2cue/burn-audio2cue.c:308-320,
static gchar *
brasero_audio2cue_len_to_string (guint64 len)
{
int sec;
int min;
guint64 frame;
if (len = 10LL)
frame = (len % 10LL) * 75;
else
frame = len * 75;
frame = frame / 10 + ((frame % 10LL) ? 1:0);
In the following analysis, I shall substract 300 to the line numbers for
simplification, so consider the first line is #8.
len seems to be a duration in nanoseconds. The control structure ll.
15-18, stores 75 times the rest of its division by one second into
frame. This is done only if len is greater or equal to one second, but
this condition is pointless since if it is strictly lower (by the way, I
think it should be removed for clarity), then this rest is equal to len
anyway.
So now, frame contain the nano-frame number, between 0 included and 75e9
excluded. L. 20, it is divided by a billion to get the frame number and
it is added one if it was an exact frame. The result is thus between 0
and 75 *included*, equal to 75 in the cases where (len % 1e9) * 75 ==
74e9.
I must be missing something since I think this case never happens, but I
am really not an expect in C so I am not sure of this divisions'
behaviour. Anyway, this is where the problem is. I shall give it a more
precise look, but do not hesitate to comment or correct my analysis.
Regards,
--
,--.
: /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar
| `-'Debian Maintainer
\_
signature.asc
Description: Digital signature
Bug#619723: cdrdao extits with .cue:14: Timecode out of range
package brasero tag 619723 + patch thanks Tanguy Ortolo, 2011-11-10 18:04 UTC+0100: So now, frame contain the nano-frame number, between 0 included and 75e9 excluded. L. 20, it is divided by a billion to get the frame number and it is added one if it was an exact frame. The result is thus between 0 and 75 *included*, equal to 75 in the cases where (len % 1e9) * 75 == 74e9. My mistake: it is incremented by one if it was *not* an exact frame. In practice, I imagine this would almost always be the case. So the result is equal to 75 in all the cases where 74e9 (len % 1e9) * 75 75e9. The attached C program allows to demonstrate it: $ ./test 9 # this is one second minus one nanosecond 0 0:0:75 I imagine that the conditional increment is meant to include the last incomplete frame in the case where a track does not exactly end on a frame. The current implementation is wrong, and it could be corrected by conditionally incrementing len *before* we start computing anything from it; however, given that a frame is only one 75th a second, I think it would be better to simply remove the conditional increment: part of a frame could be lost on the very last track of the disk but I do not think it would matter to anyone. For instance, if you replace l. 22 from my program by the commented one just above: $ ./test 9 0 0:0:75 If you agree with this solution, here is a quilt patch that implements it. Regards, -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ signature.asc Description: Digital signature
Bug#619723: cdrdao extits with .cue:14: Timecode out of range
Tanguy Ortolo, 2011-11-10 23:53 UTC+0100:
The attached C program allows to demonstrate it:
$ ./test 9 # this is one second minus one nanosecond
0 0:0:75
[…]
If you agree with this solution, here is a quilt patch that implements
it.
Oops, forgot to attach these files. Here they are.
--
,--.
: /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar
| `-'Debian Maintainer
\_
#include stdio.h
#include stdlib.h
int main(int argc, char** argv)
{
long long len;
long long frame;
int sec;
int min;
if (argc != 2)
{
return 1;
}
len = atoll(argv[1]);
if (len = 10LL)
frame = (len % 10LL) * 75;
else
frame = len * 75;
frame = frame / 10 + ((frame % 10LL) ? 1:0);
//frame = frame / 10;
len /= 10LL;
min = len / 60;
sec = len % 60;
printf(%lli %i:%i:%lli\n, len, min, sec, frame);
return 0;
}
Description: Avoid generating invalid frame number 75
The conditional increment to the frame number, which is probably meant to
avoid loosing the last incomplete frame in the very last track of a disk, has
the side effect of generating frame numbers equal to 75, when they should be
between 0 and 74 included, which results in an unburnable image.
.
While the code could be adapted to count the last frame, it is clearer and
less intrusive to the original code to simply remove the conditional increment,
and possibily loosing 1/75th a second on the very last track should not matter
to anyone.
Author: Tanguy Ortolo tanguy+deb...@ortolo.eu
Last-Update: 2011-11-10
Index: brasero-3.0.0/plugins/audio2cue/burn-audio2cue.c
===
--- brasero-3.0.0.orig/plugins/audio2cue/burn-audio2cue.c 2010-08-16 04:55:07.0 +0200
+++ brasero-3.0.0/plugins/audio2cue/burn-audio2cue.c 2011-11-10 23:44:10.232078473 +0100
@@ -317,7 +317,7 @@
else
frame = len * 75;
- frame = frame / 10 + ((frame % 10LL) ? 1:0);
+ frame = frame / 10;
len /= 10LL;
min = len / 60;
signature.asc
Description: Digital signature
Bug#619723: cdrdao extits with .cue:14: Timecode out of range
# This can either be fixed in cdrdao or brasero [1] reassign 619723 cdrdao,brasero # Make the problem description more clear retitle 619723 Brasero produces *.cue-file which isn't accepted by cdrdao (cue:14: Timecode out of range) # Broken audio disc creation is kind of bad for burning programs [2] severity 619723 grave Hi, same issue here. The critical line was INDEX 01 37:57:75 After changing it to INDEX 01 37:57:74 burning worked. Since this was also a *.cue-file generated by Brasero I'm reassigning this bug. This seems to be the right thing to do, since the bug could probably be fixed by making brasero produce correct *.cue-files or by making cdrdao more fault-tolerant. Either way, this breaks audio disc creation in a lot of cases (3 so far for me) and is therefore a `grave' bug. Best regards Alexander Kurtz [1] http://www.debian.org/Bugs/server-control#reassign [2] http://www.debian.org/Bugs/Developer#severities signature.asc Description: This is a digitally signed message part
