I’ve added a progress bar with an OnMouseDown Event as follows:
// tmrMain is a TTimer
if (tmrMain.Enabled) then begin
I := (X * pgrSong.Max) Div pgrSong.Width;
This works very well, but sometimes the progress bar reaches the end, while song isn’t yet finished. This is only the case on playing files greater then +/- 4,5 MB. Why?
The Max. of the progress bar is the value of
FSOUND_Stream_GetLength(Stream). So on some bigger files the progress bar display doesn’t work 100%, but I use the default TProgressBar component! The Min. is by default 0. The Stream variable is okay too! How can I solve this problem?
Thanks in advance…
<font size=-1>[ This Message was edited by: UnKn0wN on 2002-02-25 08:53 ]</font>
- UnKn0wN asked 15 years ago
Try opening the stream with MPEGACCURATE and use GetLengthMS and SetTime. The time routines are more accurate, the problem stems from variable bit rate encoded mp3’s.
This works for me, using the time stuff instead of the sample stuff.
If I use the MPEGACCURATE flag, the playlist loading takes too long, I’ve found a way to load files very fast from a playlist/text file, but ONLY with NORMAL or LOOP_NORMAL flags else it can take up to 1 minute to load my files from file… How can I else solve my problem?
- Anonymous answered 15 years ago
Sounds like your using the FSONGS[Index] array of songs method. I strongly recommend using one SONG and just opening everything into that variable.
I use a text file, and as I go forward and backward in my playlist a then load the file and do all the fmod code to actually allow the song to play. Except for the Initialization of FMOD which I do in my FormCreate event, I do everything else in a procedure I wrote.
As a result I have a “PLAIN” player that even with almost 1000 Mp3’s in the playlist loads in a second or two.
To see what I mean, take a look at my source of the program itself :
Should help you out, like I said, this loads right away and I never have any list take a long time to load, and I believe I use MPEGACCURATE.
If you base your program on the FMOD TestBed (Which is a very nice collection of FMOD features) don’t use the Song array.
The song array is good for playing any sound file supported by FMOD, but I would recommend using only one instead of the array. Heres what I mean :
In Delphi, we can create our own types of variables based on information we give (a very powerful feature once you get into casting), so with the testbed, we have the following type :
TSongType = record
then we declare a variable under the private declarations block (used only for this focus) :
FSongs: array [0..MAX_SONGS – 1] of TSongType;
But, instead of doing it this way, I use one instance of the FSONGS :
FSONG : TSongType;
By doing this I avoid having more than one song at a time. However, this is not what you want to do if you want to mix songs, then you need to have the array. Since I wrote a simple player where I only wanted one song to play at a time this was not a problem.
If you’re making an MP3 player, with no MOD support, then you can do away with the FSONGS type all together and just use :
Stream : PFSOUNDSTREAM;
as the variable to hold the stream data. In the FMOD_Template I mentioned above, this is what I do. Take into consideration what it is you want to write and plan it out as good as you can. The TestBed is a perfect example of a smart way to deal with multiple song types, be they MOD/MP3/Wav, or whatever.
I hope this clears things up for you, I really don’t know what else I could put down to describe the process. But I think you’ll be on your way now.
Have A Good One! 😀
Using the MPEGACURATE flag makes loading take longer because FMOD has to scan through the entire MP3 at load time to get accurate time information on the MP3. If variable bit-rate MP3s were not used, then MPEGACCURATE would not be required. But since the bit-rate can change partway through a VBR MP3, you cannot quickly calculate the duration of the MP3 by multiplying bit-rate by filesize (approximately).
Please login first to submit.