Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: Egor on August 06, 2009, 09:56:37 AM
-
I have downloaded by streaming a mp3 file of the audio of a video on youtube.When I utilized the original firmware of my sansa e280 the file were recognized and I can listen it.But now, with Rockbox, it doesn't appear on the database and when I search it on "files" the player don't play the song and pass to another.I suppose that the problem is linked to the fact that the file has a bitrate like this "~0 kb/s".Someone can help me please?thanks in advance.
-
I have been having a similar problem for a few months now. I listen to a podcast called "Stuff you should know" by HowStuffWorks.com. The MP3s used to play fine on my Sansa e260 running Rockbox but stopped at some point. Now when I attempt to play one of these files the player will ignore it and skip to another file. Or in the case of no other available file I've had it open the voice recorder. I listen to several other podcasts that play fine in Rockbox. For some reason just this one does not.
The MP3s from this podcast play fine in VLC on my computer. According the VLC's media info it is using the "mpga" codec, and is mono, 22050khz, 80kb/s.
My Rockbox Info is: Sansa e260 running r22610-090903
-
Did the *exact* same file stop playing, or did newer files by them stop working at some point? It's possible they started including something in the metadata that trips Rockbox up, that wasn't included before.
-
Can you give us a link to the file on that website so we can download and investigate ?
-
I did a little more reading through old posts. I ran a chkdsk on the player and it's clean. Also, per VLC there is no metadata at all, I don't have any other tools available to me here at work to check. I also tried setting some metadata (artist & title) via VLC just as a test and that had no impact.
The feeds RSS URL is http://www.howstuffworks.com/podcasts/stuff-you-should-know.rss
A specific example would be http://podcasts.howstuffworks.com/hsw/podcasts/sysk/2009-09-01-sysk-us-dependent-cars.mp3
I currently have the last 7 episodes on my Sansa and none of them will play.
Thanks for the help.
Edit: Newer files do not work. (Sorry forgot to answer that question.)
-
The problem goes away if I remove the first first MP3 frame, which contains the Xing VBR and LAME tag. Note that if you remove that frame, you also remove the VBR seek table, and so you may have problems when seeking.
(At the beginning, the file has a rather atypical ID3v2 tag which has an image but none of the usual text info. That is not a problem. If you want, you can remove the tag with Mp3tag.)
Edit:
The file is not VBR, so feel free to remove the frame.
You can simply run the Rockbox vbrfix plugin on the file to make it playable. Highlight the file, hold select, go to "Open With..." and choose "vbrfix".
-
Spoke to soon. That did fix it for several of the files but I have a few that still aren't working. This one...
http://podcasts.howstuffworks.com/hsw/podcasts/sysk/2009-08-25-sysk-steal-nuclear-bomb.mp3
VBR fix gets to 49% and reports that it is not a VBR file but Rockbox is still skipping it.
I think at this point I'm also going to try emailing How Stuff Works to see if I can't get any traction on their end for fixing their MP3s.
Thanks again.
Edit:
I tried removing all tags (id3v1, id3v2) using a unix tool (id3v2) and this didn't help.
-
Yes, the MP3 files are broken and How Stuff Works should release fixed versions. The problem is in the Xing/Info header. A flag is set which claims that the header contains an entry with the number of MP3 frames in the file, but that number is zero. So, Rockbox thinks the file has duration zero and refuses to play the file.
I can't really call this a Rockbox bug because the MP3 file is broken. However, being able to play broken files is good, and it might be a good idea to add support for this particular brokenness.
Don't bother with ID3 tag utilities. This is not in an ID3 tag. It is in the first frame of the file. Try getting a copy of vbrfix which can run on your computer, and see if that will fix the files.
-
I'll forward this off to them and hope they do something to fix it. In the mean time I can work around it.
Thanks again for all your help.
-
Rockbox makes sure the byte count from the Xing/Info header is reasonable and ignores the byte count if not. Seems like something similar for the frame count would be in order... Just checking for zero would be a start; making it better than that would be nice, but it might be difficult to do in a good way.
-
If you need a tester for any patches addressing this let me know, I'd be more than happy to help.
-
Thanks, but no need (a test file goes a long way). Just committed a quick fix that solves the immediate problem. More checking for bad values should perhaps be done; now I just removed a few lines of code that looked wrong. ;)