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*
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
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
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
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.
# 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
6 matches
Mail list logo
