I use the stream-functions to play mp3-files. some of them are vbr, some are not. I need to play every file (vbr or not) immediately, without scanning it before (it taktes about 3 seconds on my machine, with 10mb large files). But I also need to have exact time-accuracy for getlengthms, setposition and so on.
Since it is no problem to show the time data a little bit delayed, is it somehow possible to play the stream immediately, but scan it while it’s playing?
- Anonymous asked 15 years ago
no, that’s not my problem.
My problem is, that when the user skips some tracks, the new track needs a long time to start, because the file has to be scanned at first. I want to play it immediately (that’s possible if I don’t use the MPEGACCURATE flag), but I still need to seek the file by time, not by byte or something else.
So I need to make FMOD scan the file while it plays. If you’d call so, I need a two-task-method: The one thread plays it, the other one scans it. After scanning, all the seeking-methods must work.
Built into FMOD doesn’t exist.
A partial solution would be scan some frames (I suggest 10 or 20 frames at the beginning) of the mp3 file BEFORE loading it. If those frames have different bitrates, then the mp3 file is VBR so you must load it with MPEG_ACCURATE flag, else it can be directly loaded. Doing so, at least CBR mp3 files should be loaded almost instantly.
Any other suggestions?
I really need it! I thought of two streams, one playing immediately and the other for getting the length, but of course I can’t copy the timedata from the ‘informationstream’ to the playing ‘real’ one.
Isn’t there any way to play the file and get the information later?
Perhaps a suggestion for the next version 😉
anonymous poster was me, damn’d cookies!
You just have to know how many frames there are in a mp3 file.
The see how many frames there are in the file, just seek for every sequence of sync headers. You find a sync header when you find 11 (eleven) set bits. Then you have to multiply the number of frames by the number of milliseconds took by a frame. I think you may find useful informations on the Net about this. However it is not so hard as you may think. IF you need some sourcecode, ask me privately.
[quote="Paranoid_Android":3ismi2d6]You could disregard MPEG_ACCURATE and get all of the info you need from an ID3 function, like ID3Lib, which gives MPEG info fast.[/quote:3ismi2d6]
but what is when open without MPEG_ACCURATE , (because i did my analsysis before) when i want top open a stream and right after it, before playing, i do a FSOUND_Stream_SetTime() call… will this Seek be accurate? then this would be ok for me…. and if the seek is always accurate.. how is it handled internally? does it a real frame scan to the required position?!
have anybody here tried out the accuracy of the seeking mechanism into fmod?
Is there no easier way? Something that is already a bit automated in FMOD?
But even if I do it manually, then I still have to seek manually. How will FMOD (esp. the function Stream_SetTime) know the timedata of the file? So I have to jump to the frames by myself and I think that’s not the way someone should use FMOD. Then, I could also use another mp3-decoder an play the decoded sound via the API…
That’s also true.
I don’t really know how you may solve this problem.
Sometime ago I heard about some undocumented functions. They seem to be related to mp3 decoding, maybe there is a setposition that uses frames instead of ms.
At last a suggestion: why you don’t use ogg vorbis? Is mp3 support really need?
[quote="brett":2chsupy3][quote="Chris":2chsupy3]mdd: i tried to use the Xing (LAME uses it too) header with FMOD. It Is possble but i can’t get it very accurate timing functions.
But it is acceptable for playback
if you want the code mail me: email@example.com[/quote:2chsupy3]
looks like the xing header provides only 100 points to reference inside the file, which is going to be the cause of the innacuracy. FMOD does a similar thing, but has as many points as there are frames so it gets the exact millisecond offset for each mpeg frame. I found some of the info here http://www.multiweb.cz/twoinches/MP3inside.htm which if you wrote the code, then you already know about :). But others might find it interesting.[/quote:2chsupy3]
i did wrote the code myself but maybe i can improve it a bit now 😀
[quote="brett":h1ypzvr1]the rest of this thread already talked about seeking, maybe you didnt read all of it. id3 will not do anything for seeking . nothing. FSOUND_MPEGACCURATE will prescan the whole mp3 (headers only) when FSOUND_Stream_Open is called, which builds an offset table, so when it seeks it is accurate.[/quote:h1ypzvr1]
i read it as well…. my question is: when i open the stream WITHOUT FSOUND_MPEGACCURATE , how is the seek then done… the file is not scanned and i call the fsound_stream_settime() function… is it accurate or not…? and yes.. id3 is no solution for that problem. even if 80% would have this information inside… 20% would still not!
Please login first to submit.