I have a lot of insanely low bitrate audio books on my MK2A player, and the player does not handle them gracefully.

These files are downloaded from audiobooksforfree.com (I highly recommend this site if you haven't been there) and are encoded at 16 KB/sec constant bit rate. (That's not a misprint: 16 KB/sec!) The sound quality is poor, but listenable with a couple of the EQ bands attenuated by a full 30dB.

The player does not do a good job of keeping track of where it is in these files if the player is powered down during play. When powered back up, perhaps 1/4 of the time it will start up where it left off; perhaps half the time it will start up wherever it started last time; and the remaining quarter of the time it will start at some random location within the file.

Much of the time, the FF/REW buttons will not function in these files. And on the occasions when the FF/REW buttons do work, the time-elapsed/time-remaining counters are bogus: if I am playing a 15 minute file and play it to completion the numbers will be fine. But if I FF in the file, the actual placement in the file will be about double what the elapsed-time counter shows, that is I will actually be seven minutes into the play time of the file when the counter shows three and a half minutes.

I only experience these problems with the 16 KB/sec files; music files encoded at a more reasonable rate perform normally.

Does anybody else have extremely low bitrate files?

tanstaafl.

16KB/s is quite a reasonable rate - I assume you meant 16Kb/s.

Are the files mono? It's possible that that may make a difference.

16KB/s is quite a reasonable rate - I assume you meant 16Kb/s.

Yes.

Are the files mono?

Yes. They are taking up about 115 kilobytes of disk space per minute of playtime.

This means that if I had Paul Grzlak's player, I could put just about exactly two years of audiobooks on it!

One more little discrepancy I have discovered... If I pause the player (without powering it down or even timing out of standby) when I restart the player the elapsed time counter will be the same as when I paused -- but the play location in the file will be somewhere else, usually about five minutes ahead of where I paused it.

My only workaround is to only pause or stop the play exactly between files.

tanstaafl.

Greetings!

You rang???

I have had the problem with audiobooks, but I use VBR files and attribute it to the lack of Xing header.

Constant bit rate... Hmm... A thought: have you tried to compress another file down to that bit rate to see if it is the bit rate vs. the files themselves? Have any kind of MP3 diagnostic utilities shown any problems with the files themselves?

Another thing (and a long shot) - check the files really are CBR, by playing them on some other player that shows instantaneous bitrate as it's playing (e.g. XMMS). I've found that uploading a VBR file that's missing the VBR header is misrecognised as CBR based on the rate of the first frame. While you're at it, you could try seeking etc. in the other player, and see if it works there.

check the files really are CBR,

Well, emplode says "16kbits/s mono"

MP3TagStudio refuses to "correct" the VBR headers -- claims the files are CBR.

WinAmp plays the file as 16kbps, 11KHz, says it is mono and has no problems skipping back and forth through the file, maintaining proper time counters.

I just have to believe that the codec in the empeg player just doesn't like very low bitrate CBR monaural files... I can live with it.

tanstaafl.

I suppose if you had the room, you could re-encode the files at a higher bit rate. I know it is pointless for audio purposes, but then you may be able to get proper use of the time and seeking. Not really a good solution to the problem, but a temporary workaround if nothing else.

In reply to:

---

16kbps, 11KHz, mono

---

The sample rate is another possibility. The hardware in the player is quite fussy about sample rates. Can you encode a test track at, say 128kbp/s 11kHz mono CBR, and see if you get the same problem? If you do, that rules out the bitrate as a likely cause.

I have a 8kb/s mono file, but it's just 10 seconds of silence, so I've not noticed anything odd. If I get time, I might encode something more substantial to play with.

The problem may be that 11kHz, I believe, isn't a valid mp3 sample rate. 32, 48, and 44.1 kHz are the only valid rates I'm aware of. But let me see if I can find out something else. There has to be something somewhere that claims 11kHz as a valid sample rate, as mp3s don't record the actual sample rate in the file; they just record a dictionary entry.

Edit: Yup. Every doc I can find has the same info as this one, and it says that 11kHz is not a valid sample rate, although maybe if it was MPEG 2.5 Layer 3, a sample rate of 11025 Hz might get reported as 11kHz, but MPEG2.5 doesn't exactly seem likely.

The problem may be that 11kHz, I believe, isn't a valid mp3 sample rate.

I don't actually know that it is 11khz; only that WinAmp says that it is.

The files play just fine as long as I don't ever interrupt the play and expect to restart them where I left off.

Re-encoding them in some other format is not an option since they are downloaded as-is from the audiobooksforfree.com site on the internet and the original .wav files are not available.

tanstaafl.

EncSpot thinks it's MPEG 2.5 layer 3.

This is what it generates for the Dracula audiobook.

Bitrates:
----------------------------------------------------
16 |||||||||||||||||||||||||||||||||||||||| 100.0%
----------------------------------------------------

Type : mpeg 2.5 layer III
Bitrate : 16
Mode : mono
Frequency : 11025 Hz
Frames : 17639
Length : 00:15:21
Av. Reservoir : 156
Emphasis : none
Scalefac : 28.3%
Bad Last Frame : no
Encoder : FhG (ACM or producer pro)
Lame Header : No

--[ EncSpot 2.0 ]--[ http://www.guerillasoft.com ]--

- Trevor

Re-encoding is always an option:

lame --mp3input in.mp3 out.mp3

(with other sensible Lame options, of course).

lame --mp3input in.mp3 out.mp3

But... wouldn't taking an already very low quality MP3 file and re-encoding it only make it sound worse? I mean, the data isn't in the original file, and not even lame can provide what wasn't there in the first place... can it?

tanstaafl.

--[ EncSpot 2.0 ]--[ http://www.guerillasoft.com ]--

That is a neat program. Thank you for the link.

tanstaafl.

I've always found that one generation of reencoding is not terrible. And, given the fact that it's not as if it's exceptionally high quality to begin with, I wouldn't be surprised if the difference was unnoticeable. Then again, I wouldn't be surprised if the difference was tremendous.

I would definitely try reencoding it.

I would also think that if this is reproducible, then it's also a bug in the empeg. But it might just be a documentation bug in that they forgot to mention that they don't support MPEG2.5 or something like that. Maybe it's a bug in the ARM decoder. Regardless, there's a bug there somewhere....

In reply to:

---

wouldn't taking an already very low quality MP3 file and re-encoding it only make it sound worse?

---

As Bitt says, it will reduce the fidelity, which may or may not make it sound worse. But I was proposing this as a test, rather than as a solution. If we can work out exactly what it is that causes problems for the player, we might be able to offer more detailed and constructive comments to the Empeg team and/or the decoder developers. More constructive than "it don't work", I hope.

Greetings!

If I recall, the file plays fine; it is only on the fast forward, rewinds and pause / resume that there are issues. This implies a positioning / tracking problem very similar to the VBR without (or with broken) Xing headers. Granted, I realize we are dealing with CBR here, but it might be that the code for the seek is assuming a higher, more "standard" bit rate or (failing that) going to a VBR-esque seek, looking for a header or (failing that) trying to "fake it".* If so, it might be possible to manually craft a Xing header that would give the player application a roadmap to better locate positions in the file. After all, a CBR file is only a VBR file that doesn't vary very much...

* Note: all of this is speculation, never having seen the code that actually does any of this.

In reply to:

---

it might be possible to manually craft a Xing header that would give the player application a roadmap to better locate positions in the file. After all, a CBR file is only a VBR file that doesn't vary very much...

---

That's a cunning move, Paul. You should be able to write a constant VBR map (as the values will be 0, 1, 2, 3, ..., 255 for all CBR files), and simply concatenate the audio file onto it.

I've now confirmed this with some MPEG 2.5 layer 3 files

• 16kb/s 11kHz CBR mono
• 16kb/s 11kHz CBR mono with VBR tag
• 8kb/s 8kHz CBR stereo

and in all cases I see the described behaviour. Additionally, the Seek Tool time does not agree with the music - it appears to be where the player thinks it is (i.e. where it would be if it had resumed from the right place) not where it actually is. So I don't think it's a matter of the player saving the wrong position, as would happen if buffered output was being lost. It's getting totally lost when seeking back to the correctly-saved position.

(That last one was pretty awful to listen to...}

and in all cases I see the described behaviour.

OK, then it isn't just me doing something dumb (other than trying to play 16 kb/s files on a stereo that expects high quality files to work with)

I'll post this bug to the alpha list team and have it assigned an official bug number.

Thanks for all the help checking this out.

tanstaafl.

on the occasions when the FF/REW buttons do work, the time-elapsed/time-remaining counters are bogus

FITNR (the player was miscalculating seeks in MPEG-2.5 files).

Peter

Greetings!

I wonder if this fix would help for those VBR files that are missing Xing headers... Would you be interested in a file to test???

FITNR

Now that is impressive -- fixing a problem with files the player was never spec'ed to handle!

Thank You!

tanstaafl.

I wonder if this fix would help for those VBR files that are missing Xing headers...

Sadly no; that's a completely different problem.

Would you be interested in a file to test???

No thanks, we've got loads!

Peter