** Changed in: gst-plugins-ugly0.10 (Ubuntu)
Assignee: (unassigned) => me_sudeep (sudeepshetty4all)
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/35112
Title:
MP3 track times
I confirm, that adding xingmux solves the track length issue in Karmic.
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a direct subscriber.
--
desktop-bugs mailing list
Unfortunately this problem is very much still alive I did NOT have this
problem with Jaunty. I've recently done a clean install of Karmic and two
problems occur:
1. The track lengths are reported as way too long, i.e a 4/5 min track is
reported as 30-40 mins or so
and..
2. the file size of
Well adding xingmux to the gstreamer pipeline as described above seems
to fix the track length bug in Karmic.
However, it does not fix the file size problem. Should I report this as
a seperate bug?
Mike
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this
I can confirm that the following command line outputs right bitrate and
right track time in Totem on the Arch Linux distribution:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0
preset=standard ! xingmux ! id3v2mux
It should be alright as well in both Ubuntu Karmic and Lucid, I
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 the
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=enc
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.
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You
the problem is still alive
sound-juicer 2.26.1
rhythmbox 0.12.3
gstreamer0.10-ugly 0.10.11
gstreamer0.10-ugly-plugins 0.10.11
using pipeline
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 vbr-
min-bitrate=64 vbr-max-bitrate=192 ! id3v2mux
oh yeah, and it doesn't affect only
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
Honestly, it looks like this bug has lived forever because it's assigned
to the wrong component. I'm sure Sound Juicer can be patched to
accurately create the null frame - I don't think this is a problem with
the gstreamer framework or how its invoked at all.
--
MP3 track times are incorrect
Thanks Derek! Finally some *help*. I'm on intrepid with bells and
whistles and was shocked to find out after ripping 9 Gigabytes of my
audio CDs using
audio/x-raw-int,rate=44100,channels=2 ! lame preset=extreme mode=0 !
id3v2mux
that most players (including my zen) would be very confused at the
There's a tool called vbrfix. It looks like it is available as a debian
package. I don't know about ubuntu. Gentoo has an ebuild named vbrfixc.
It works well for me.
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this bug notification because you are a member
Same problem almost any play show correct time, even checkmp3 says its ok, but
rythmenbox mess up the time:
xu...@delilah:~/music/Jazz/Django Reinhardt/Nuages - Tears/CD 1$ checkmp3
Django\ Reinhardt\ -\ After\ You\'ve\ Gone.mp3
Possible ID3v2 frame found, skipping
Using Ubuntu 8.10 and this still seems to be an issue. Has any progress
been made?
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a direct subscriber.
--
desktop-bugs mailing
Even though mp3 is not officially supported I think it's very bad that this bug
is not fixed for over two (2!!) years.
I understand the reasons to not officially support mp3 but it's a
quasi-standard in the digital world.
Does anybody work on this bug any more? Or will we have it still in
Due mp3 support can not be officially supported (I guess), this really
IS kind of a showstopper bug.
Ripping only CBR mp3s as a workaround is not a good solution. Anyone
know why this is so hard to fix? In feisty this worked fine for me. (or
at least in edgy) I was hoping this would be solved in
I have a problem in Hardy Heron, but this only started happening
recently.
My pipeline is :
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-
quality=2 preset=extreme ! id3v2mux
I'm getting some song lengths over 10 minutes for a 5 minute song. Some
song lengths are over 50
I have the same problem in gutsy. what a pain. i can't burn cd's
because gnomebaker thinks all my 3 minute songs are 15 minutes long.
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which
Can confirm this in Gutsy. Seems to happen with VBR settings. In Gutsy
(for me) there's also the problem, that pipelines including xingmux
will not appear to be selected in sound-juicer, though are listed in
gstreamer pipelines.
However, instead auf xingmux I tried ffmux_mpeg (ffmpeg packages) it
This problem still occurs in Gutsy.
Even using xingmux the times are not correctly reported in some applications,
like Amarok.
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a
Using xingheader instead of xingmux (see comment #17) fixed the problem
for me. It seemed to worked for a while, so I stopped paying attention.
Recently I dug into it again and noticed that the problem reappeared, at
least since January 9th 2007.
Right now:
- xingheader ! id3v2mux results in
Output of checkmp3 rippedfileusingxingmux.mp3:
Possible ID3v2 frame found, skipping
An expected frame was not found. Expected it at offset 0x614 (BYTE 1556), now
at offset 0x615 (BYTE 1557).
FILE_NAME rippedfileusingxingmux.mp3
GOOD_FRAMES 12760
BAD_FRAMES 1
I can also confirm that the bug still exists in Feisty.
--
MP3 track times are incorrect
https://bugs.launchpad.net/bugs/35112
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a direct subscriber.
--
desktop-bugs mailing list
For what it's worth, I have this same problem with LAME on Windows, too,
but only when I have it set to encode through the standard input. Then,
iTunes doesn't read track names correctly either. Perhaps the issue
lies with the encoder?
--
MP3 track times are incorrect
This is still an issue in Feisty (7.04). This pipeline also fails to get the
correct track times when playing the resulting mp3 file with Amarok:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 !
xingmux ! id3v2mux
--
MP3 track times are incorrect
This should not have been closed as fixed, as this is still a bug. The
following pipelines do not have correct ID3 or track times in Edgy:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=2 !
xingmux ! id3v2mux
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc
Closing as fixed then...
** Changed in: gst-plugins-ugly0.10 (Ubuntu)
Status: Confirmed = Fix Released
--
MP3 track times are incorrect
https://launchpad.net/bugs/35112
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Same problem here. Ubuntu 6.06.1, libgstlame 0.10.3, sound-juicer
2.14.4, rhythmbox 0.9.4.1
For me, using the xingmux-plugin it works in xmms, but still not in
rhythmbox. By chance, I seem to have found a solution that works (at
least for me), though:
The gst-lame documentation (gst-inspect-0.10
Same problem.
Dapper 6.06.1
Soundjuicer 2.14.4
GStreamer Pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc
preset=1001 ! xingmux ! id2v3mux
My results:
- the bitrate is shown correctly in Nautilus, Totem and Rhythmbox
- the track time is shown correctly in Rhythmbox
- the track
** Tags added: mp3 vbr
--
MP3 track times are incorrect
https://launchpad.net/bugs/35112
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
I'm seeing this bug with 6.06.1 LTS. Track times are incorrect in
Rhythmbox, Serpentine and Cowbell. The first 2 showed exactly the same
way off duration, but Cowbell was only a little off.
Track times for Banshee, VLC, Totem and Nautilus properties seem fine.
(The command I used was
Neither seems to work. However: the time DOES report right in Xmms and
BMP, and the file access is a little less wonky (previously, the
incorrect files used to take longer to process and select - I had
assumed that this was because of the incorrect times).
However, Rhythmbox still sees the time
Sebastian, do you know if that's the correct way to encode?
--
MP3 track times are incorrect
https://launchpad.net/bugs/35112
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
GonzO, could you install gstreamer0.10-plugins-bad and then try the following
pipelines:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=0 vbr=4
vbr-quality=2 ! id3mux ! xingmux
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=0 vbr=4
vbr-quality=2 ! xingmux! id3mux
Latest version of SJ as of today. MP3 profile line:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=0 vbr=4
vbr-quality=2 ! id3mux
Result: Tags are actually correct, but track times are not. They may actually
be worse: an 8:00 song reported as 53:57. The whole CD rip is
I've also experianced this bug. It is VERY brutal when exporting these mp3s to
iPods or other mp3 players. Seeking was totally disfunctional with the ipod
with these messed up track times. I had to rerip my library with grip to get
it to work...
--
MP3 track times are incorrect
37 matches
Mail list logo
