| Summary: | duration support for music_mad.c | ||
|---|---|---|---|
| Product: | SDL_mixer | Reporter: | Ozkan Sezer <sezeroz> |
| Component: | misc | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | admin, uso.cosmo.ray |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | duration support for music_mad.c | ||
|
Description
Ozkan Sezer
2019-12-17 19:02:08 UTC
One bad thing about this patch, as far as I can see, is that it scans the whole mp3 file. Using the Xing frame, if present, would have been much better.. > Xing frame
Do you know kow to get it? One note that some bad MP3 files may result an incorrect length detection. The full scan of a file gives the accurate length value. It's even able to return the length for files are failing with mpg123. Btw, I have lots of these files are failing to return length with mpg123. So, try to get the Xing frame if possible, otherwise, do a full file scam to calculate the length.
(In reply to Vitaly Novichkov from comment #2) > > Xing frame > > Do you know kow to get it? One note that some bad MP3 files may result an > incorrect length detection. The full scan of a file gives the accurate > length value. It's even able to return the length for files are failing with > mpg123. Btw, I have lots of these files are failing to return length with > mpg123. So, try to get the Xing frame if possible, otherwise, do a full file > scam to calculate the length. Never wrote code for it myself, but there are lots of documentation on the web. The available code (the ones I know) are GPL or LGPL, so I am not touching them. Bad thing about full file scan is that it is slow. A 500k mp3 is OK maybe, but a big file may cause an unwanted lag at start. Okay, once I get my home, I'll try to check out some. About the lag: it's very dependent from a file size and the disk performance. In my experience, the lag while opening regular MP3 files is pretty short (less than 0.1 second), but when speaking about bigger files like more than 10 MB that obviously will be longer. Digging guts for me isn't a problem, I should give a shot to support a Xing frame for a faster length detection. Some links from the web: (there are certainly more.) https://www.mars.org/pipermail/mad-dev/2009-January/001385.html https://wiki.hydrogenaud.io/index.php?title=MP3#VBRI.2C_XING.2C_and_LAME_headers http://gabriel.mp3-tech.org/mp3infotag.html https://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header#VBRHeaders Changing importance type to 'enhancement'. Mp3-mad isn't even enabled by defalut due to license issues, therefore low-priority. Maybe it's reasonable to merge this thing now if it looks fine? It's now a blocker that prevents me to backport a big MusicInterface exchange from MixerX. (In reply to Vitaly Novichkov from comment #7) > Maybe it's reasonable to merge this thing now if it looks fine? It's now a > blocker that prevents me to backport a big MusicInterface exchange from > MixerX. Speaking for myself: It does _not_ look fine to me. If it is blocking you to prepare a patch-set, you should change things on your end. We should not bother ourselves with this. Closing as wont-fix. |