Support and General Use > Audio Playback, Database and Playlists
Wrong bitrate+mpeg-layer of ripped MP3's
(1/1)
DO1FJN:
This is no rockbox bug.
My idea is a 'smarter' exception handling for defect MP3's.
My problem:
I have a lot of MP3s recorded with an older streamripper (linux console version, V1.61.11). These files are often split incorrect and don't have a valid first frame.
The behavior of rockbox is:
- displaying random bitrates and mpeg-layers like 'MP1 446pbs'
- in result rockbox calculates a wrong playing time
- the file is played correct by the decoder thread but sometimes I hear a short noise at the beginning (wrong decoding the truncated first frame)
How make it better?
I think the decoding-thread can feetback a 'change' of the layer + bitrate to the control-thread.
Or:
More pre-decoding to determine that the first frame was truncated and take the infos from the first valid frame.
Deluxe decoding (idea):
The decoding-thead can keep a file-rest (incomplete frame) and fix the next title, if this title has the opposite frame-part. With this idea I could listen the ripped stream gapless and with no noises between the tracks.
With newer streamripper versions I have now an identical end / begin frame: I hear a short repeat. But is ok - I can live with this. Handling of these exception makes the decoder to complex, I think: Every last frame of a file must be compared with the first frame of the next track (and skipped if equal)...
I will upload some sample files, if needed, and email the link to developer who asked me.
rockbox = great work.
Best regards,
Jan, DO1FJN
Llorean:
Why not use a ripper that doesn't create broken, or repeating, files? It sounds like you want Rockbox to solve the problem of other software creating bad files.
There are many formats that support true gapless, or you can use Lame MP3 which supports at least gapless playback even though the files technically have a hidden gap (that never gets played unless your MP3 player doesn't support the gapless tags, but Rockbox does).
DO1FJN:
>Why not use a ripper that doesn't create broken, or repeating, files?
I use an actual ripper, but I HAVE thousends of MP3-files on CDs ripped years ago.
I suggest my idea, special exception handling, have no disadvantages. Only more stability, no wrong track times, bitrates and mpeg-layers.
Kind regards
Jan
Llorean:
It seems to me that Rockbox should report that a file is invalid, rather than trying to work around the invalidity of it, if it's not a valid file.
senab:
Try using Foobar2000's rebuild MP3 stream feature.
Navigation
[0] Message Index
Go to full version