Not sure if this is a mAirlist problem or a hardware related problem.
I am testing mAirList at the moment and I notice in AUTO mode, the schedule time on the playlist shifts after the programme has been running for a few hours.
For example:
In the original play list, I have:
13:00:00 song 1
13:05:00 song 2
.
.
15:00:00 Song 1
15:05:00 Song 2
.
.
16:00:00 Promo 1
16:00:30 Promo 2
Having run the programme for 2 hours, the playlist time chnages to the following:
.
.
15:00:45 Song 1
15:05:45 Song 2
.
.
16:00:45 Promo 1
16:00:45 Promo 2
The time shift varies and it rather frustrating. I wonder if I have set something by mistakes.
Or do you think it might be a hardware problem? My suspicition is on the external hard disk I am using to load the song. Would it be possible that each time when the next song is being loaded, it creat a slight delay, and therefore after a few hours, the delay adds up?
45 seconds in one hour is a long time. You should notice these delays as gaps during playback.
I assume that the actual duration of some file might be different from what the playlist has guessed before. For example, when you drag an MP3 file into the playlist, mAirList will look into the MP3 header in order to determine its duration. Once the file is loaded into a player, the duration is updated with what BASS.DLL reports as the actual duration. Especially when VBR files are involved, this might be different from what mAirList “guessed” before.
However, this could still be caused by slight delays while loading the files, which add up after some time. In this case, here’s two things which might help:
Switch off the “only use a single player for automation” playlist option, so that two or more players are involved. The second player will load and prepare the file while the first player is still playing the previous item.
Unless VBR MP3s are involved, switch off BASS_STREAM_PRESCAN in the sound card config for all players. (This options makes BASS.DLL scan the complete file in order to determine its duration - which takes about a second, and is not necessary for CBR files.)
Finally, if you want to make sure that Song 1 starts exactly at 15:00:00, despite any delays, just set the fix time in the Properties dialog of that item.
Thanks for the quick and extensive reply. I will try to work on those suggestions.
The shift can sometime be a few minutes, even just after 3-4 hours. Is there a minimum hardware requirement in term of memory and processor speed?
As I have a varies source of audiuo files at the moment, I am not sure if all of them are CBR, what will happen if I have a VBR MP3 and have BASS_STREAM_PRESCAN switch off? Would the files just refuse to load?
Perhaps I should just run a conversion programme to make sure I only have CBR files.
Is it just the scheduled times in mAirList that are ‘slipping,’ or is it the Window system time which is ‘wandering’ from the correct time? In other words, have you checked whether or not Windows is keeping correct time during the two hours?
If not, you might need to sync your PC’s time with the Internet every 15 mins or so to prevent drift.
If your PC/Windows time is correct, can I ask whether or not your Playlist has the option set which ‘updates backtimings when idle?’
Finally, you say that the times are correct in the ‘original playlist.’ How are those times set exactly? Are anoy of those times fixed, or not? Are there any other things happening/not happening which might be different whilst the playlist is being played out?
I have to admit that this is a problem with the internal design of mAirList, which does not allow to “pre-load” files unless you use at least two players in automation. It might be compensated by a fast CPU, but the original problem remains (I will need to think of a solution). As mentioned above, use fix times when you want to make sure that a certain item will start on time.
Anyway, I still believe that these delays are not the problem here. It’s rather the “wrong duration” problem.
Perhaps you can enable logging and then compare the actual start time of each with the one calculated before? You will easily see whether there’s a constant slide of a second or two before each file, or if it’s just a single file causing the delay.
As I have a varies source of audiuo files at the moment, I am not sure if all of them are CBR, what will happen if I have a VBR MP3 and have BASS_STREAM_PRESCAN switch off? Would the files just refuse to load?
No, but the player will show a wrong duration, which can be greater or smaller than the actual one. And you will not be able to set cue points accurately.
The problem is that MP3 files have no header. They’re just a stream of so-called “frames”, each of which has its own header. In order to determine the duration of the file, you have to inspect each single frame and calculate the sum of the duration values. This is what BASS_STREAM_PRESCAN does.
Generally, each frame can have a different bit rate, and thus have a different size (in bytes). In CBR MP3s, each frame “happens” to have the same bit rate and also the same size. So you can just inspect the first frame, and multiply its duration by the number of frames (= file size / frame size). This is what BASS does without the flag set, and it’s much faster than scanning the complete file. However, with a VBR file, you will get a wrong result, because the first frame will most likely have a bitrate different from the average bitrate of all frames.
Thanks CAD. I need some time to check the details.
I don’t think Windows Time is slipping, but since I sync it to internet once a day, I might not have picked that up. At the moment, windows time seems correct, but I wiill doublecheck by disabling the sync and see.
Updates Backtiming when Idle is “OFF” for the Playlist option.
As I am only strting to test the programme, I am only doing the absolute basic with the playlist. It is created by dragging files from the browser directly to the playlist area one by one. The original time schedule was taken as reported by mAirlist. The “drifted” time is taken as reported by mAirlist after a few hours.
I do have varies source of audio files, (wav and MP3, CBR and VBR) so it could be a file problem. I also notice mAirlist will refuse to load some files when the file name is in “Simplified Chinese (GB Code)”. It is fixed by renaming it to english or Taiwan BIG 5 code.
One possible related problem which I haven’t have time to investigate in detail is that some of the MP3 will load on the playlist and play, but will not show any “duration”, time will only added to the the playlist AFTER it has been played. I have avoided using those files, but the time shift problem remains.
Please also see my other post, not sure if it is related?
Jospeh, your untimed files are very probably the VBR MP3s, at a guess!
I have seen your other posting and there is a possibility that the Chinese (?) version of Windows may have some issues that other international versions do not: I just don’t know, sorry! :-\
Can I ask what if anything you use as a virus checker, malware scanner, and firewall, and whether all of them are up to date with the latest detections? Also, when did you last do a FULL (entire HD) check of your PC for viruses, malware, and so on? Finally, is there any other software running permanently ‘in the background’ on your PC, like any Messenger or VoIP/telephone program such as Skype, for example?
I now have run 3 players, and I notice the “gap” between each audio files has now disappeared. (Previously I only have one player)
The time still slip, but I use the fix time function at some key point so it is now a managable situation.
I will try to load everything into C drive and run it on a faster computer when I can get round to it and see if there is some further improvement. Will also try to convert all files to CBR and see if that bring futher improvements.
I also think the virus checker is a problem, but since I am also streaming from the same computer at the moment, I do need to have the anti-virus. Perhaps, I can just reply on the windows firewall and then run virus scan once in a while.