I hit this problem too, though not reliably reproduceable: it happens
after ripping 5-6 discs. Quitting the application fully (not just
closing the windows, but making sure the background process (indicated
by the small icon in the menu bar) is closed too) and restarting
"solves" the problem for a
On Fri, 21 Aug 2009, GonzO wrote:
> "This problem can be solved by adding "xingmux" to the gstreamer
> pipeline."
>
> No, it can't - see all the above conversation about the
> xingheader/xingmux pipeline in this bug report. Fixes it for some apps,
> but not for others.
Files I have ripped with th
This problem can be solved by adding "xingmux" to the gstreamer pipeline.
For example, when I changed the setting for "CD Quality, MP3 (mp3 type)"
from
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-
quality=0 ! id3v2mux
to
audio/x-raw-int,rate=44100,channels=2 ! lame name=e
It looks like the "vbrfix" program available through Synaptic fixes this
issue - that is, after processing an MP3 file with vbrfix, the track time
is correctly reported.
>From the description in synaptic:
Unfortunately, the problem is that many MP3 MP3 decoders estimate the
time of a MP3
Public bug reported:
Binary package hint: hal
I load an SD card into my IBM X40's built-in socket. Dmesg dutifully
reports:
[50845.78] mmcblk0: mmc0:3b99 SD02G 2011136KiB
[50845.78] mmcblk0: p1
However, nothing else is logged, and hal doesn't notice the insertion.
I am able to mount
** Attachment added: "Dependencies.txt"
http://librarian.launchpad.net/6916409/Dependencies.txt
** Attachment added: "ProcMaps.txt"
http://librarian.launchpad.net/6916410/ProcMaps.txt
** Attachment added: "ProcStatus.txt"
http://librarian.launchpad.net/6916411/ProcStatus.txt
** Attachm
