I have a strange issue where some albums - when I add a track to play, it loads Eg: where say a track is 3.53 min it loads as 10.59 min
That’s one specific example
Dolphin too is showing in the info, as 10.59
VLC loads it to play as 3.53
On 05/11/2014 01:16 AM, caf4926 wrote:
>
> I have a strange issue where some albums - when I add a track to play,
> it loads Eg: where say a track is 3.53 min it loads as 10.59 min
> That’s one specific example
> Dolphin too is showing in the info, as 10.59
> VLC loads it to play as 3.53
>
I blame baloo.
On a serious note, is it always 3x the length? That seems like a very
specific multiple and the fact that its only happening in KDE
applications is really weird. Also is it for all files or just some
specific format that it might have issues viewing data for? Oh and what
happens if you try to seek to some part past the “actual” length of the
track?
–
Bring the Penguins Back! https://features.opensuse.org/316767
openSUSE 13.1
KDE 4.13.0
I’m looking in to the details
Pretty sure this existed before the change in kde
The files are .mp3
It will be later before I can get back to the files now…
I did do a quick convert of a file to .ogg and it loaded correctly
I don’t think it’s exactly 3x but it’s on that same ratio each time
I’ll check on the playback skip beyond point later
Media info from affected track
Format : MPEG AudioFile size : 7.18 MiB
Duration : 3mn 53s
Overall bit rate mode : Constant
Overall bit rate : 256 Kbps
Album : Wrecking Ball
Album/Performer : Bruce Springsteen
Part/Position : 1
Part/Total : 1
Track name : Track 01
Track name/Position : 1
Track name/Total : 11
Performer : Bruce Springsteen
Composer : Bruce Springsteen
Genre : Rock
Recorded date : 2012
Writing library : LAME3.93
Cover : Yes
Cover type : Cover (front)
Cover MIME : image/jpeg
URL :
Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Duration : 3mn 54s
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 7.14 MiB (99%)
Writing library : LAME3.93
From a unaffected track
Format : MPEG AudioFile size : 4.74 MiB
Duration : 3mn 30s
Overall bit rate mode : Variable
Overall bit rate : 189 Kbps
Album : The Complete Greatest Hits (disc 1)
Track name : Take It Easy
Track name/Position : 01
Performer : Eagles
Genre : Rock
Recorded date : 2003
Writing library : LAME3.98r
Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Duration : 3mn 30s
Bit rate mode : Variable
Bit rate : 189 Kbps
Minimum bit rate : 32.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 4.74 MiB (100%)
Writing library : LAME3.98r
Encoding settings : -m j -V 3 -q 0 -lowpass 18 --vbr-new -b 32
Trying to play beyond the real track length just stops playback. So in amarok the actual track stops playing when the progress slider is only part way along.
The only odd bit I see in the BS track is this part:
Stream size : 7.14 MiB (99%)
But I have other albums that tracks say the same
Stream size : ?.?? MiB (99%)
But not with the same issue in amarok
That’s a really old version of LAME (3.93) the affected tracks appear to be encoded with. Is it some sort of framing bug that was present in 3.93 that some decoders (VLC ?) can deal with but others cannot ? Try batch recoding using Audacity at the same bitrate parameters.
Just as another thought what version of ID3 were they tagged with, I’ve seen that cause strange issues, version 2.0 I seem to remember was problematic but age and a poor memory lets me down.
I guess VLC does everything with its own packages which can deal with it but Amarok relies on some system wide decoder?
Amarok and KDE’s file information (so dolphin) use taglib AFAIK.
But from looking at VLC’s dependencies, it seems to use taglib as well?
Strange then isn’t it
Well, maybe VLC uses something else for getting the track duration, and only uses taglib for other tags like Artist or Title.
I haven’t looked at the source code…
But kfilemetadata (used by dolphin) definitely uses taglib, and I think Amarok as well.
Btw, taglib contains a small program with which you could show the tags/audio information:
tagreader *filename*
I suppose this would show the incorrect duration/length as well?
title - "We Take Care Of Our Own"artist - "Bruce Springsteen"
album - "Wrecking Ball"
year - "2012"
comment - ""
track - "1"
genre - "Rock"
-- AUDIO --
bitrate - 96
sample rate - 44100
channels - 2
length - **10:24**
So there is the problem. Any ideas on how VLC avoids relying on taglib?
Maybe it calculates it itself?
Or it uses libmad/libmp3lame?
No idea, but if taglib can do this, why should some other library/application not be able to do it?
Well, I guess the main question here is whether there’s a bug in taglib or the mp3 files are broken in some way.
Maybe try something like “mp3_check” or “mp3val” (available from Packman).
There’s also a newer taglib version available in the multimedia:libs repo (1.9.1, whereas openSUSE 13.1 ships with 1.8).
Which version do you have? Maybe try the other one? (the lib itself is in the package “libtag1”)
I don’t see anything related to this in the changelog though, except maybe “Many smaller bug fixes and performance improvements”.
PS: taglib only calculates the length, when no Xing header is found (and this is only possible of course if there’s a constant bitrate).
Otherwise the value that’s stored in that Xing header is used.
So maybe the Xing header is invalid? No idea how VLC would get the right length then, though. Maybe it ignores the header altogether?
OTOH if the header is detected as invalid, taglib would not use it but calculate the length differently. So it could also be that it detects the header as invalid (and calculates a wrong length, maybe because the files are VBR), whereas VLC uses the values in the header.
Another (probably even more) useful program is “mp3diags”, also available on Packman.
Especially one of those transformations might help you:
| Remove mismatched Xing headers | Sometimes the number of frames in an audio stream is different from the number of frames in a preceding Xing (or Lame) header, usually because the audio stream was damaged. It’s probably best for the Xing header to be removed in this case. If the audio is VBR, you may want to try “Repair VBR data” first. |
|---|---|
| Repair VBR data | |
| If a file contains VBR audio but doesn’t have a Xing header, one such header is added. If a VBRI header exists, it is removed. If a Xing header exists but is determined to be incorrect, it is corrected or replaced. Only the first audio stream is considered; if a file contains more than one audio stream, this should be fixed first. | |
| Rebuild VBR data | If a file contains VBR audio, any existing VBRI or Xing headers are removed and a new Xing header is created. Only the first audio stream is considered; if a file contains more than one audio stream, this should be fixed first. |