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 *befor
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 anot
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 f
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 be
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
# 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 program
6 matches
Mail list logo
