• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Plugins
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by yelped - 2009-10-16
Last edited by Buschel - 2011-01-06

FS#10678 - Mp3encoder encodes short, squeaky files.

I don’t know if this happens on all targets, but on my Fuze v1, when I encode a WAV file to MP3 with mp3encoder included with Rockbox it outputs very short, squeaky files, i.e. an 18-minute recording becomes about 1 and a 1/2 minutes and all you hear is squirrel voices.

This happens on all the builds I’ve tried, which is random builds from when the Official Test Builds were provided up until, and including, the current build.

Closed by  Buschel
2011-01-06 17:37
Reason for closing:  Fixed
Additional comments about closing:  

Fixed with r28976

I have tried this with r23201 on an e200 and an e200v2 (AMS SoC like Fuze) and mp3encoder worked properly on both devices. The file I used was a 5 minute long wav file.

I tried it again with r23173 and it didn’t work, I tried it again with r23242 which is the current build, and it still didn’t work. Upon further investigation, it turned out that every bitrate has this bug, however, with bitrates above 256kb/s, it became 4.2 times larger than the original file, and it refused to play. Could be that the Fuze records the WAV files with parameters that the mp3encoder included in Rockbox can’t understand?

I can’t comment much on the Fuze since I do not have one, but the e200v2 is very similar to the Fuze regarding the processor, memory, etc. The main differences are the LCD controller/orientation and buttons. The binsize and ram usage on the Fuze are a little higher than the e200v2, which could possibly be the reason it works for me and not for you. The Fuze would not use different parameters than the e200v2.

Here are some things to try, if you haven’t already:
1. Clear the settings to default values. If you backup your .rockbox/config.cfg file (or the entire .rockbox directory), you can restore it after the test to return to your custom settings.
2. Try a different file. This would rule out a problem in your source file.
3. Upload a sample of the failing file to see if others can reproduce the problem. Of course, make sure that the sample fails on your Fuze.

1. Tried that, didn’t work.
2. Also didn’t work.
3. Will do.

Thanks a lot!

PS: I meant that the voice recorder in the OF doesn’t record with normal parameters. I wasn’t sure if your WAV files were recorded with the OF, or ripped that way.

Here it is.

Ok, after looking at your sample, I have been able to reproduce your problem on my e200v1.

The problem seems to be caused by the source file being sampled at 24000 Hz. I took my wav file and loaded it into Audacity. This wav is a song that was ripped from cd, sampled at 44100 Hz and 5:02 long. In Audacity, I changed it to 24000 Hz and exported the file to my e200. The resulting wav play without problems. I then encoded with mp3encoder at 192kb/s. This resulted in an mp3 that was 3:01 long and unintelligible.

I tried loading your sample into Audacity and changing it to 44100Hz and then encoding the resulting wav with mp3encoder, but that did not help. It was still shorter than the original and unintelligible.

Converting your test file to mp3 in Audacity or foobar2000 results in a properly working file.

Maybe now that we have these additional details, somebody knowing more about mp3encoder will be able to help troubleshoot this problem.

Thanks a lot! That’s why I asked if your WAV file was recorded with the OF.

The attached patch solves some major issues with the encoder:
1) set stereo = (cfg.channels==2) instead of stereo = true when calling init_mp3_encoder_engine()
2) correct the read_samples() function to support reading mono pcm and convert this to stereo interleaved (internal format for encoder).
3) remove stereo-to-mono conversion as this is not needed on mono files

This is still not 100% fixing the issues with the above file, but the sound is far better. The mp3 plays double speed with correct pitch.

For further debugging I need a short sequence in a 44.1kHz-mono wav and a 24kHz-stereo wav file.

Following patch introduces more detailed user error messages. Additionally it throws an error message and aborts encoding if samplingrates != 32/44.1/48 kHz are used. This avoids generating unusable files until the underlying error – somewhere in the handling of MPEG2 layer3 format – is fixed.

Submitted with r28973.

Attached patch fixes MPEG2 Layer3 encoding. Input samplerates of 17/22/24 kHz are supported now.


Available keyboard shortcuts


Task Details

Task Editing