I have just bought a portable MP3 player - a Freecom Beatman Flash - but I am having wierd problems with LAME MP3's on it. Basically, unless I use the "--allshort" flag when encoding, all the MP3's have artifacts - they click, pop, slow down and droppout. I think its something to do with the long block encoding used in LAME, because in normal mode (short and long blocks) there are some artifacts, but with --noshort, the artifacts are loads worse.
With Nero's MP3 encoder and EasyMP3 encoded files, the player works fine, but I can't get decent output from LAME unless I use --allshort, in which case the output plays fine on the player, but is crappy quality sound.
Is there any way to alter the encoding of long blocks that may fix these problems in LAME? I have tested with 3.94a8, 3.93.1 and 3.90.2 ICL, and all have the same problems with my player. Help me please its driving me nuts!

i'd return the mp3 player.

Could you try with --nores ?

I would return the player, but I CAN get VBR MP3's that work using EasyMP3 and/or Nero which sound only slightly less good (if at all) than LAME encodings. It's just bugging me really - also, I don't know whether its the player thats at fault or LAME. I would like the added flexibility of LAME though.
What does --nores do btw?

Sorry - I figured out what --nores does. BUT it doesn't make any difference enabling it I'm afraid - the file size increases quite a lot, but the frequent clicks and slowdowns of the file playback are still present just the same. This is very wierd.
BTW the settings I am using as a base is "--alt-preset standard", and I am using RazorLame 1.1.5 (if this makes any difference). I am currently using the 3.94a8 version of LAME - please let me know which one I should be using for testing.
I appreciate any suggestions for Lame tweaks - I'll try 'em all! This is so annoying

Have you tried --strictly-enforce-ISO? Or -b and -B (to limit the VBR "flexibility"), perhaps with -F? Could be that the player doesn't like low-bitrate frames (32 kbps mainly).

--strictly-enforce-iso won't help if --nores does not help.

You might try -F and -B 256

I was going to post the same remark about --strictly-enforce-iso :-)

What does the -F switch do ?

-F is forcing to not go under the minimum specified bitrate, even when there is digital silence

Oh. Yes, I remember now.. that was used when designing the --grammophone command line :-)

Now back to the thread subject, i think it's a pity that no certification is needed for selling a mp3 player !

There is an ISO mp3 standard, with some test bistreams. If you can not decode properly those test streams, then your player is not MP3 compliant.

In the case of this specific player, it's likely to not be able to decode those streams, and then not beeing mp3 compliant.

(but I have not seen yet any fully compliant hardware mp3 player)

Now I understand :



Their test bitstreams don't include 32kbps frames, and not even 128kbps and above !
Also, nothing to check correct handling of VBR

To develop such an advanced (well, ok, when it was designed !) format and not even encourage testing a complete HALF of the different modes of operation, is a crying shame IMHO !

No, those are not the compliance test bistreams. Those are just test (as in demonstration) samples.

Compliance bitstreams are:
ftp://ftp.tnt.uni-hannover.de/pub/MPEG/au...peg1/compliance

Enabling -F and/or -B 256 doesn't seem to have any effect on the crackling problems I am having. Thanks for the suggestion though. The player will play 320 and 32kbps CBR files fine, so I don't think its anything (directly) related to min or max bitrates in the VBR files. I'm still pretty convinced that its at least got something to do with the way long blocks are encoded in LAME.
Oh BTW, the XingMP3 engine in Audiocatalyst also gives (even more) artifacts on my player, if this helps - actually, I seem to remember reading somewhere that Xing only uses long blocks, so if this is right, it makes me think even more so that the problem is related to some difference between the way FhG encoders 'do' long blocks and the way Xing and LAME does them. Is this possible?
Please keep posting suggestions!

PS Are there any reference/testing VBR MP3's that I can try on the player?

Oops - I just tried Xing on "Normal" quality VBR mode instead of "High" and the files generated are pretty much perfect (but sound quality is quite a lot lower). Maybe this helps someone to figure out what the problem is with this player and how I can tweak LAME to get around it!

Just a shot in the dark, but maybe the player is not able to deal with very sharp increases in bitrate...

Have you tried... --alt-preset 160? (just for choosing a number)

Maybe with a -B 192 for testing purposes...

Also, if you can get your hands on EncSpot to check the bitrate graph of the correctly working Xing VBR file, that might give some ideas...

I think you may be right about the sharp bitrate changes thing. I tried using -alt-preset 160 and there were only very few clicks. Still I'm not sure why disabling long blocks (using --allshort in LAME) fixes this problem - anyone know? Also, is there any way to restrict such sharp changes in bitrate (some kind of 'smooth-bitrate-change' option) in LAME?
I also got hold of a copy of EncSpot - here are the results of running it on the two XingMP3 files I encoded, one on "Normal" quality VBR setting (which works ok) and the other on "High" quality VBR (which pops and clicks like mad):





To me, this seems to show that the only real change was in the average bitrate, but then EncSpot doesn't seem to give any information on the bitrates of adjacent frames (so its impossible to tell whether there were sharp bitrate changes in one and not the other). Both files were entirely made of long blocks, and were also all most entirely MS frames.

I would like to know what player exactly this is, so's I can do a little "research"...

specs for his player:

Some players are unable to handle high bitrates frames.

You might try adding -B 192, then -B 224, then -B 256. This will limit frame maximum size to the specified value.

But if it were just a case of it not handling high bitrate frames, then why does the player work with 256 and 320kbps CBR files fine? Does the -B mode work differently in VBR (other than setting the max bitrate (VBR)rather than the actual bitrate (CBR))?
I'm currently testing with --alt-preset standard -B 192/224/256 to see if it makes a difference though. I'll report back soon. I had a look at an FhG encode and it had very few high bitrate frames (some at 224 and hardly any at 256, with NONE at 320), whereas for the same file, Lame put in loads more 320 and 256k frames.

Well, I tried limiting the bitrate on VBR files using -B and the artifacts do decrease to nearly nothing at -B 192, but are still present at -B 224 and worse at -B 256. So this prompted me to check CBR encodings, and I found that LAME encoding at 320kbps works fine, but at 256, the file is FULL of pops and clicks on the hardware player (at least 1 a sec), and 224 has quite a lot (though much less than at 256) of artifacts, with only 192 or less working ok.
In Nero (FhG) these bitrates all work fine, and I did notice that in EncSpot the 'Scalefac' figures for the Nero generated files were really low (like <1%) as opposed to between 10 and 20% in the LAME files. Also, the Nero files all used exclusively 'SS' JS frames, while LAME used mostly 'MS' JS frames with a few 'SS' frames. The 'Scfsi' flag was also present in the LAME files but not in the Nero ones (as was the 'Xing Header'). Does any of this help in the diagnosis?

BTW I tested all encoding bitrates in JS and normal Stereo mode, and with --nores and --strictly-enforce-iso flags on and off - none of which made any appreciable difference.

Unfortunately it's helping me in one diagnostic: your player is ...well... how to say it without beeing offending......

My advice would be to try returning the player if you can and get another model....

Well, yeah - to be more accurate, the player is crap with LAME encoded files. Like I said in an earlier post, I CAN get working files from an FhG encoder, and from Xing in some cases, so the search for a set of LAME command line args that will work is more of an educational thing rather than a deep need (that and the fact that LAME is more tweakable, and therefore capable of slightly better sounding files). And other than the problems with LAME, the player is pretty good.
Anyway, I was playing around more with settings and with the idea that the player doesn't like sharp changes in bitrate, or very high bitrates, with LAME, I found that this command line:
--alt-preset standard -Y -m s
gives me very nearly perfect files. I guess this is largely because the -Y command simultaneously removes most sharp bitrate changes, as well as lowering the overall bitrate. Oddly, if I let the file be encoded in the default joint stereo mode, the player gets up to its old tricks. However, when encoding with this preset, the forcing of simple stereo doesn't seem to add much to the size of the files I have been testing on (a couple of hundred kb on a 6Mb file), but I can't decide whether there is any quality difference (would one be expected?). If anyone can think of any other options that might help removing any remaining sharp bitrate increases, or general bit-saving-with-near-transparency options, please pass them on!
I'm a bit puzzled by the problems with 256 and 224k files still - surely there must be something that LAME is doing differently at these bitrates compared to the 320k bitrate in CBR, and if I can figure what that is, it could give me an idea of where exactly the incompatibility between my player and LAME actually lies. So, any suggestions on this welcome too.

Thanks for all the replies so far!

So I guess the bottom line is...

return that mp3 player right away!

Sorry!

EDIT: I mean, Joint Stereo is perfectly ISO compliant, it is 100% standard. If the player has issues with JS mp3 files at certain bitrates, the player is buggy. More than enough reason to return it. Surely there must be some other flash player with proper mp3 support...

Maybe try use --verbose option to check diffs

Its OK everyone - it is the player (I guess you all figured that already). I used the Radium codec, and it has the same problems, but only in joint stereo mode, at 256, 224 and 192 - no idea why lol - stoopid player. Nero's FhG encoder doesn't use hardly any frame sizes other than 160 and 192 in VBR mode (even on the highest quality setting - what a pile of crap!), which I guess is why it works better. It also does something wacky when you encode CBR at high bitrates (eg. 256) - it flags the file as joint stereo, but all the frames are simple stereo! No wonder it works better - stoopid Nero trying to trick me!
Anyways, thanks for all the advice - you guys (and girls?) rule!

Do you think you'll return the player then?

Dunno yet - I'm waiting for some answers from Freecom. I suggest you use their email support form to harass them (like I have) if you are having the same problems. I have already got them to admit that the ONLY encoder they know works is Nero, which is $65 with the mp3 plugin! They say that they have verified that LAME doesn't work, neither does BladeENC. I emailed them back and hopefully they will give me some info on when (or whether) a fix will be available.
I am torn between returning it and not - on the one hand, it does sort of work so long as you don't use 192, 224 or 256 joint stereo files, and I haven't seen another player that looks as good and has the same features, and small form factor, for the same price. On the other hand, the bitrate bugs are REALLY annoying, especially since most of my cd rips are high bitrate VBR (the file type the player hates the most - just my luck ), and I don't really like the feeling that I have been fobbed off with an unfinished player. If anyone can recommend a player that is similar (but that works properly!) to the Beatman Flash, please lemme know!

BTW Are you the "BIG Phil" from the Freecom support forum?

Oh, btw - I have found that this set of command line flags:
--vbr-new -V 2 -Y --nspsytune --nssafejoint -h -m s
tends to make mostly Beatman-compatible files in LAME. Dunno if you need the --nssafejoint flag, since I'm forcing simple stereo. If you still get clicks, try using -V 3 instead of -V 2 (or even -V 4). If anyone using a Beatman is reading this forum, I hope this helps!

Yes I am "that" BIG Phil and I feel exactly the same way. I've been looking at the alternatives but none of them are ideal. I'd be really interested in any information you receive from them about a fix. If they don't have one planned then I might well return it. Then again many of my mp3's are in a 128 cbr format so it doesn't affect me as much. Although, I would like to encode any future albums in VBR mode. At the moment I just don't know. I'm hoping some answers from Freecom will make my decision for me.

Imagine if the next version of FhG encoders is using a few different parameters. It will not work anymore with your player.

Are you willing to stay forever with the only encoder that is known to produce files that your player is able to play?

I don't use FhG, I use Lame... and the player works fine at low to medium cbr. It's just irritating that vbr doesn't play very well. If they don't show clear intentions to fix it then yes I will return it.

While waiting for a response from Freecom , I have been thinking and testing again and I was wondering, is there a switch that disables the use of scfsi in Lame? What about disabling the use of scale factors? I'm not really bothered about any effects on sound quality/file size at this point, as I'm just testing.
Also, did anyone think of a reason why all-short-block files work ok all the time when 'normal' files don't (i.e. files with long blocks or short and long blocks)?
Incidentally, I have also found out that simple audio files (i.e. with test tones, or oscillating tones etc.) encoded in Lame play back fine on the player at all bitrates even 256 and VBR - its only 'proper' music files that seem to give problems, if this means anything to anyone!

Thanks to any repliers

Shortblocks have higher bitrate demands. Using Shortblocks force the bitrate up often up to 320kbps which is compatible with your player.

Is there not any way to do the things I mentioned in my last post? I only want to test it because I have found that Blade (I know, its old and dodgy) encoded files will play fine on my Beatman Flash at all bitrates inc. 192, 224 and 256. Using EncSpot on the files, it seems that they are plain stereo (obviously), and they dont use scfsi OR scale factors (the "Scalefac_scale" checkbox is unchecked, and the "Scalefac" attributes value is "not used" in EncSpot) - hence why I wan't to try and disable them in Lame - and there are some short blocks, but mostly long ones (so the problems can't be down to just the block type).

BTW LordofStars, what I understand your post to mean is that a VBR file using short blocks will work because there are more 320k frames. However, I have managed to get files encoded with --allshort that have nearly the same bitrate distribution as those encoded with all long blocks, or mixed block lengths (as indicated by EncSpot anyway). Still the all-short-block files work flawlessly (they just sound rubbish ), whereas the mixed or long blocks only files have problems, so I don't think your suggestion applies to these problems. Thanks for the suggestion though!

The answer has been found:
On the mp3encoder ML, someone encountered the same problem, and found the cause.

Your decoder is not accepting different block sizes for L and R.
Quick way to test:

Encode a track in stereo that you know is not working. Then try adding "--noshort" for test1, and "--shortonly" for test2.
Test1 and test2 should play correctly.

If this is the case, the "-d" switch should allow you to have files working on your player.

Makes sense.... I know dual channel is a waste of bits but how much of a quality hit will it be?

dual channel would make no sense, dual channel encodings are 2 mono channels (ie channel 1 german, channel 2 english).

I guess it's a bit confusing, but -d isn't the same as -md. The latter turns on dual channel mode, the former forces lame to switch to short blocks in left and right channel at the same time.

Then why does Xing fail? It only uses long blocks.

Edit - Added Quote

Would -md work as well? or even -mm? That way neither channel would differ and therefore would not use different blocks... I still agree -d is a better idea than either of mine.

Well I tried the suggestion of Gabriels, but I found that using
--alt-preset cbr 256 -m s
there were pops and clicks; using
--alt-preset cbr 256 -m s --allshort
(since --shortonly didnt do anything) there were no problems at all; using
--alt-preset cbr 256 -m s --noshort
there were pops and clicks (I think slightly more than the first file).

So it doesn't look like its the block switching thats the problem. My stoopid player just doesn't like long blocks at certain bitrates! Interestingly, the only differences I could see between the files was that the "Scfsi" mode was only off on the --allshort file (the one that works), and that the scale factor use was only 3.3% in the --allshort file, and ~10% on the other two. Is there no way to disable Scfsi and/or scale factor use?

Thanks for the suggestion anyway - and btw, the new standard3 preset seems to me as good as the existing standard, but with much lower bitrate (which means more of the files encoded with standard3 work on my player ).

Those options will probably be available in the next release.

I read something about the scfsi in lame-dev. I believe tak said he had added those options. Am I correct? What were they? or are they even available in alpha9?

Thx
lossysan

Yeah, does anyone know of a compile that has the option to disable scfsi in Lame?
Also, I was trying the -d flag the other day, and I'm not sure whether its actually doing anything, because Lame comes up with a warning message saying
"WARNING: -d is obsolete"
and when I looked in the docs, -d was used for turning ON allowing different block types between the stereo channels. This seems to have become the default setting, so does -d actually do anything in the latest compiles?

I have just tried the new alpha10's presets - preset standard works ok on the player, but I noticed that now the use of the -Y flag (which used to make a very slight quality drop, but massive bitrate savings) has little effect on problems/file size. preset medium seems to work well (haven't tested many files yet), especially on some source files that standard made problematic mp3s from - does this preset have the -Y flag built in btw?