conclusion to "I love you but you piss me off" :)

[teh_stinch]

The bug is with amarok not lame. Vbr files without xing headers are perfectly vaid mp3 files. amarok should not incorrectly assume files are cbr if it can't find a xing header.

[Aq]

The bug is with amarok not lame. Vbr files without xing headers are perfectly vaid mp3 files. amarok should not incorrectly assume files are cbr if it can't find a xing header.

We have these options here:

1. Patch amarok to do things correctly
2. Patch lame to do things incorrectly but amarok's way
3. Use lame in a different way to make things that work with amarok
4. Use something other than lame

1 and 2 are pretty hard; 2 is obviously the best, assuming what you say above is right, but nobody on the LR team has the requisite skills. 3 would be ideal if it were possible, but the comment from the lame guys suggests it isn't. So that leaves us with 4, use something different, which it looks like Matt is going to try.

[teh_stinch]

Having downloaded the latest episode in mp3 and looked at it the file actually contains a xing header.
Which is fairly obvious as it was encoded by lame and lame always includes a lame tag which is an extension of the xing header. I don't know why that didn't click earlier.
You can read the spec of lame tags here
http://gabriel.mp3-tech.org/mp3infotag.html

So if the files have xing headers the problem must be something else.
I also tried stripping the id3v2 tag from the file but amarok still reported the wrong track length.

[valent]

Maybe it's time I accepted that lame is broken.

I encode the shows with the vanilla oggenc and lame in the Ubuntu repositories.

Before I encode the next show, I'll see what else I can find to do the job.

Happy hunting...

[valent]

Maybe it's time I accepted that lame is broken.

I encode the shows with the vanilla oggenc and lame in the Ubuntu repositories.

Before I encode the next show, I'll see what else I can find to do the job.

Matt please try amarok with mp3fixer script, but make a backup of mp3 file first. To me it looks like it is fixing length of LugRadio.

[valent]

The bug is with amarok not lame. Vbr files without xing headers are perfectly vaid mp3 files. amarok should not incorrectly assume files are cbr if it can't find a xing header.

as you can see by looking at this link:
http://bugs.kde.org/show_bug.cgi?id=130185

the bug IS in lame, not amarok. lame creates files with bad XING headers.

[teh_stinch]

I downloaded the latest episode in high mp3
lugradio-s04e08-181206-high.mp3
Then used this tool from codeproject (win32 only) and loaded the mp3.
http://www.codeproject.com/audio/MPEGAudioInfo.asp



From the xing header the number of frames is 141,619.
There are 1152 samples per frame and the sample rate is 32,000 Hz

Times the num of frames by the samples per frame to get the total number of samples.

1152 * 141,619 = 163,145,088 samples

Divide the total num of samples by the sample rate to get the track length in seconds.
163,145,088 / 32,000 = 5098.284 seconds
5098.284 seconds converted to HH:MM:SS = 01:24:58.24

Foobar2000 gives the play time as 1:24:58.221. The difference is caused by foobar2000 using the extra info in the lame tag so the track length can be calculated exactly.

[neuro]

Please check out the reply from lame developers:
https://sourceforge.net/tracker/?func=d ... oup_id=290

Yeah, the reply says the apps (i.e. Amarok) are broken, what's your point?

[valent]

Please check out the reply from lame developers:
https://sourceforge.net/tracker/?func=d ... oup_id=290

Yeah, the reply says the apps (i.e. Amarok) are broken, what's your point?

Have you read this bugreport here:
http://bugs.kde.org/show_bug.cgi?id=130185

They say that the problem is in wrong XING headers, and if Amarok would calculate all mp3 songs that would be unacceptable for large music collections. So I think that you came to wrong conclusion that Amarok is broken.

[neuro]

Other apps seem to handle single channel vbr just fine; again, what's your point?

FWIW, I'm re-encoding this week's hashlugradio (new show out today at noon!) with --vbr-new as recommended in the KDE bug report, so we'll see how that goes.

[neuro]

After trying this, and noticing iTunes still didn't give a shit about how long the ep actually was with regard to displayed time left (but still playing the ep in entirety), I have discovered this infamous Xing header is "old school". LAME is undoubtedly the best free MP3 encoder, and I personally don't plan to stop using it to encode hashlugradio unless something catastrophic happens. I see the best way forward is fixing Amarok to read single channel VBR files "properly", instead of relying on some crufty old relic from another encoder, and petitioning Apple and other manufacturers to sort out their VBR support too.

[teh_stinch]

The problem with mp3 is that the file is divided into frames. Every frame in the file has a fixed number of samples and the sample rate is constant.

Calculating the length of a cbr file is easy because every frame is the same size. To get the number of frames and thus the number of samples in a file you just do filesize/sizeof(frame). Once you have the total number of samples you can divide it by the sample rate to get the play time.

With vbr files frames have different bit rates so frames differ in size. In order to find how many frames there are in the file you have to walk through the file counting them.
Xing saw this problem and created a header that contained among other things the number of frames in a file.

Fraunhofer created an alternative VBRI header but AFAIK their encoder is the only one that uses it and lots of decoders don't support it.

The xing header certainly hasn't fallen out of use. Far more decoders understand it than vbri and most encoders use it including lame which is probably the most used encoder.

[valent]

Yipeee, this bug is going to be fixed...
check out the #20 comment on
http://bugs.kde.org/show_bug.cgi?id=130185

Have a happy New Year!!!

Valent.

[valent]

Yipeee, this bug is going to be fixed...
check out the #20 comment on
http://bugs.kde.org/show_bug.cgi?id=130185

Have a happy New Year!!!

Valent.

It's been months and still no new version of taglib has been released...
This is sad. Only thing you can do is to go to http://bugs.kde.org/show_bug.cgi?id=130185 and see that they won't release new taglib version "until it is ready"... I don't get it, why don't then they apply the patches and increment taglib for .1 version and release it and continue on with their developement?

Can somebody explain this to me?

[valent]

Yipeee, this bug is going to be fixed...
check out the #20 comment on
http://bugs.kde.org/show_bug.cgi?id=130185

Have a happy New Year!!!

Valent.

It's been months and still no new version of taglib has been released...
This is sad. Only thing you can do is to go to http://bugs.kde.org/show_bug.cgi?id=130185 and see that they won't release new taglib version "until it is ready"... I don't get it, why don't then they apply the patches and increment taglib for .1 version and release it and continue on with their developement?

Can somebody explain this to me?

This finally looks like a fixed issue! Great!

Cheers,
Valent.