time calculation serious problem , help

[moh001]

your program RadioBoss is really awesome , and has got really very great powerful functions and tools , for that i want it to be the main program in the station i work in , but till now i cant make it so , because of a mortal bug ive noticed recently ..
the time calculation is not good even after turning off gapkiller and crossfading , and the current program we use has a better accurate calculation , and in the station i work with  this is really significant ..

after too many efforts i gave , i've finally figured out what's up .. your program just calculates hours , and seconds ! , the program we use calculates hours , minutes , seconds and  parts of second !

example : our current program ( RealPlayer ) calculates a playlist as 20 minutes 30 seconds
your program ( RadioBoss ) calculates the same playlist as 20 minutes 2 seconds , after playing the realplayer has the better accuracy , and this error gets bigger the more tracks we add !

so can you fix this bug ? and if yes, could you please give me the approximate time you would do so ?

 

[djsoft]

According to RadioBOSS the playlist duration is 28 seconds shorter than in RealPlayer?

Start with checking individual tracks in the playlist, their durations. The cause can be that one of the tracks is in a format RadioBOSS doesn't support, therefore its length is zero.

Internally RadioBOSS calculates duration in milliseconds (1/1000 sec), so there's no precision problems. We just don't show the total playlist duration with fractions of seconds as there's no reason for doing so.

 

[moh001]

no, not 28 seconds ,sorry, there were actually 14 seconds as i remember , i just was trying to give examples to get you know what i mean ..

i can assure you there is always difference between RadioBoss calculation and RealPlayer calculation , i can see this in every playlist i have , and RadioBoss always has the less calculation because it doesnt seem to calculate the parts of seconds and am gonna prove it now :

first of all my vision is 4.8.3.0 , the last one so far

here we go :

let's test 20 tracks, by RadioBoss :
start playing ...

http://im33.gulfup.com/bQ4aZ.jpg

as you can see the 20 tracks are 14 minutes according to the RadioBoss calculation

now let's calculate the tracks manually [ minutes and seconds merely ] :
[ you can use online calculator to calculate them , such as this site that i used
http://www.unitarium.com/time-calculator ]

03:57 + 00:08 + 00:02 + 00:07 + 00:14 + 00:08 + 00:14 + 00:05 + 01:27 + 01:26 +
00:05 + 00:13 + 00:08 + 00:27 + 00:15 + 04:03 + 00:10 + 00:13 + 00:19 + 00:19 =  14:00 !

14:00 is exactly the calculation of minutes and seconds for the 20 tracks, and it is exactly what RadioBoss calculates ! then , where are the hidden second's fractions ?! why don't they appear in the result as seconds ? , hidden fractions of seconds will turn into some seconds after 20 tracks , wont they ?

that categorically shows that it doesn't calculate seconds parts

see after 14 minutes see what happened :

http://im34.gulfup.com/avcps.jpg

then RadioBoss actually played them in 14:08 , then the next track went at the second after this ..
8 seconds error for 20 tracks about 14 minutes duration , we use some times 90 tracks for 6, 7 hours  ..

now, let's see the RealPlayer's calculation for the same 20 tracks :

http://im32.gulfup.com/CUICn.jpg

see , there are 8 seconds added above the manual calculated result that we got above ( calculation of minutes and seconds for the 20 tracks  )

after playing them with RealPlayer , they took 4:11 to end [ the real time ] , and  not 4:08 , means there are 3 seconds error , i think jumps between tracks cause that , jumps take fractions of seconds , i hope you would make a tool deals with these jumps, and i hope you would make a tool merges GapKiller actions into the duration calculations the way you've done with the crossfade ..

at end , here it is :

minutes and seconds calculation for the 20 tracks are 14 minutes [ with no fractions of seconds ]
RadioBoss calculates them as 14 minutes , then there are no fractions of seconds were calculated
RealPlayer calculates them as 14 minutes and 8 seconds , that means it has calculated the fractions of seconds internally , and the sum for these fractions is 8 seconds .

 

[djsoft]

Thanks for such a detailed explanation. I think there's actually a bug - it will be fixed in the next update.

Regarding the actual playback time. Usually it takes about 50-100 milliseconds to start a track. For 20 tracks the sum of startup times will be about 1-2 seconds. Which is very close to what you observe.

Gap Killer is applied on track startup - program doesn't know in advance how much silence there is until track is started... The only option would be to scan tracks in the background - probably we'll add this in the future.

 

[moh001]

and thank you for this fast responding ..

i'll be waiting for this new update with seconds fractions taste ..
could you please give me an approximate release date for this update ?

"  For 20 tracks the sum of startup times will be about 1-2 seconds "

i think you are taking about the jumps that i mentioned , if you made a tool deals with this , the calculation would get up to extremely high level of accuracy, extremely high really but of course after adding fractions of seconds into the calculation and with turning gapkiller off or making it scans all the tracks at first then adding the scan result into the startup calculation ..

" The only option would be to scan tracks in the background - probably we'll add this in the future "

yes , thats what i meant , to make it scans them all, then includes the scan result within the calculation , it would be very awesome like this ..

 

[djsoft]

Beta version will be released this month, hopefully next week.

Regarding high level of accuracy for Start Time, why do you need it?

 

[moh001]

oh , good news , hope this bug will get fixed in that beta vision

well , i'll try to explain this to you , in my station there is a work plan that should be followed everyday, we have blocks of tracks that should be played out at specific times , such as commercials , and other blocks should end at specific times for a live program or news brief  to go out ..

to be specific the extremely high accuracy is not extremely required at the daylight since we are dealing with short playlists , so RealRlayer accuracy is good , although it would be very good if we could have it ..

its highly required when we are dealing with too long playlists , such as nights , at night we make long playlist 8-12 hours, and some recorded blocks should go out at specific times during the night , the less accuracy would mess something up , plus it would always disrupt the working team , specially when the program gives them inaccurate start times , and inaccurate calculations ..

so, the less accuracy the less quality, and we are looking for quality ..

i hope you got me ..

note \ the start times feature in you program is really awesome and very helpful for me and for a lot of my friends who are working in this field , u know we are calculating start times for each blocks of tracks manually by our brains every time we make a long playlist , and this feature would be helpful as i think , but till now its a bug for me since its inaccurate, so i'll be waiting for the new update ..

my regards dear

 

[pety]

I do not have much expectations about "time calculation". We asked for time calculation accuracy long time ago. Very little improvements. But if there are many people who ask for time calculation accuracy maybe RB team will think hard to find a better solution.

 

[djsoft]

moh001
It is possible to increase accuracy, but it still won't be 100%. It takes ~50-100ms to start a track. It can take longer if a file is located on a network, you have antivirus installed, a read error occurs... Also crossfading precision is 30ms - it means that if you have Mix (overlap) point set to 5 seconds(*), next track can start anywhere between 4.97s and 5.03s. And there are many other factors. On a long playlist all this will sum up to several seconds (or, worst case, minutes).

To run commercials and other blocks at specified times I'd recommend you to use Scheduler: http://manual.djsoft.net/radioboss/en/scheduling_playback.htm

(*) The next version will detect Mix point based on a level, which makes calculations even more complex.

I do not have much expectations about "time calculation". We asked for time calculation accuracy long time ago. Very little improvements. But if there are many people who ask for time calculation accuracy maybe RB team will think hard to find a better solution.

There were several improvements I hope you found useful.
We should balance between complexity/CPU usage and accuracy. Currently the calculations are fast and I'd say good enough.

 

[moh001]

l'm aware of the difficulties you have , and you're doing great , my respect ..

but the improvement is still possible as you said , so let me suggest you some thoughts i thought about ..

" It takes ~50-100ms to start a track "

you see, you have numbers , so why don't you make a button that lets users play with the calculation by
these small numbers ? i mean to add - for example - 50-100ms to the calculation for each track in the on-air list ? , you know as an indemnity ..

you can make the same for the GapKiller, if you cant make it scan all the tracks yet ..

" It can take longer if a file is located on a network, you have antivirus installed, a read error occurs "

simple , as we are seeking accuracy, so we don't play network tracks , and as for the other things we have a workstation computer , so these things don't bother us at all , they almost have no effect .. [ you can notify users about such thing ]

" Also crossfading precision is 30ms "

does the current crossfading [ crossfading  without level detector ] have this ? or you are talking about the new feature [ corssfading with level detector ] ? , i think you are talking about the second one , so i'd suggest you the same thing, make a button that lets us add milliseconds in order to offset such missed milliseconds .. or make this feature optional, so if we want more accuracy just can turn it off ..

at last, you may gather all these accuracy things in a menu/bar/widget/whatever ..

as for your recommendation , thank you , i saw the schedule feature , its really great and helpful one , it's very help in making specific blocks go out in a specific time , i liked it ..

but unfortunately, sometimes it cant help, since sometimes we want the blocks before these scheduled blocks to end before them exactly ..

i have actually more suggestions for other subjects , but for me now , please, just don't forget to make milliseconds take place in the calculation , so i can let RadioBoss speak ..

my regards ..

 

[djsoft]

you see, you have numbers , so why don't you make a button that lets users play with the calculation by
these small numbers ?

It's an average. Depends on CPU, HDD speed, etc. On a slow PC running at low memory, opening a 200Mb chained OGG file can take about 2 (!) seconds... On a Core i7 + SSD drive it takes about 10ms.

i have actually more suggestions for other subjects , but for me now , please, just don't forget to make milliseconds take place in the calculation

This is on the list, I think improvements will be made soon. I don't feel that we should go that deep (like adding settings to control playlist time calculation), but something will be improved.

Regarding other suggestions feel free to post them here as well

 

[moh001]

It's an average. Depends

i know it's an average and depends ,  that's why i said " let the users choose ", so if a user has a bad computer , he can choose to add 2 seconds or whatever he sees desired , if another has a high computer he can choose 10ms or whatever he sees desired , that's my point ..

I don't feel that we should go that deep

to be that advanced , i feel you should ..

Regarding other suggestions feel free to post them here as well

well , i'll be waiting for the upcoming beta version , play it , then drop all the suggestions i have for the full version .. 

 

[pety]

well , i'll be waiting for the upcoming beta version , play it , then drop all the suggestions i have for the full version .. 

I talked about my requests about time syncronisation but I was very disappointed. Dear moh001, you will be  dissapointed too about your request. The answer will be the same: this request it is not necessary or it cannot be solved more than that. We will work hard to find bugs, to contribute for improvements with our requests, but some things...

RB is the best for us, but time syncronisation is a must have for our needs.

 

[djsoft]

to be that advanced , i feel you should ..

Time calculation have to stay totally automatic,  no settings will be added to control it. The reason is simple: there are too few people who need.
But the code will be improved internally for better start time calculation.

I talked about my requests about time syncronisation but I was very disappointed.

Most of your requests were implemented and all of the bugs you reported were fixed

Please understand, it's not possible to implement every feature request. Some features are hard and/or expensive to implement. On the other side those features add almost no value to the program. Those features are low-priority.

Here's a good article by the way: http://en.wikipedia.org/wiki/Pareto_principle

... the Pareto principle can be applied to optimization efforts. For example, Microsoft noted that by fixing the top 20% most reported bugs, 80% of the errors and crashes would be eliminated.

For start time calculation we already did 20% effort and got 80% of the result. Additional efforts have diminishing effect.

 

[pety]

I know you do the best. I implemented RB to another radio station. They want to buy it soon becouse RB is fast, low resources consumer and no sql database server.

But I will continue to ask for time syncronisation becouse we need it, not a trifle.

 

[djsoft]

Synchronization will be added some day...

Here's the funny fact. The longest time between feature request and its implementation was 5 years - a feature to detect DTMF tones. I don't think time synchronization will beat this

 

[moh001]

dear Pety ..

firstly , thank you for joining us ..

secondly , before the requests or the suggestions i made , i had pointed over a bug  [ RB doesn't calculate milliseconds ] , and it's supposed to do so as he said , i proved it to him , then he said yes its a bug and it will be fixed , so its not a request its a bug that should be fixed for their own good , and for me, if they do't take this serious problem as serious , then its done for me ..

 

[moh001]

The reason is simple: there are too few people who need

who told you they are too few people ? it's just they are too few people who get here and express it to you , plus a lot of people just surf the programs and see what is the best one for them and don't know really what they want , just if they saw a good feature that sounds good to them would say " oh ! this is it ! " , and when they saw a program that looks bad to them would just drop it to another one .. so you sometimes as a professional company have to get to the people not just waiting for their requests to be too many in order to take them in mind ..

i'd disagree with you about the pointless of making a button that lets us offset the missed milliseconds , do you know what make some stations look more professional [ much better ] than others ? simple , the tiny details like what i suggested you , why do you think am trying to get rid of my player for yours ? simple , it will fix tiny details in my station's playback , let me take the GapKiller as example , it's dealing with milliseconds mostly, then why have you made it ? , means why do you care about these milliseconds and don't care about the milliseconds am talking about ? , you see you have to take this as serious as you do with the GapKiller feature , in order to get more professional , and saying its pointless is really out of professionalism in my point of view ..

about the cost , how much would it cost to make a button that adds some milliseconds to the calculation as an offset ? ..

you know these tiny things would make someone choice , you know i have a friend now in my mind that if i now go to him and just say to him " hey buddy , i've found a player calculates the start time for each track " , he will " No Way ! show me ! " and will make his station buy it , such as what i am planing to do with my station , but if then i say " it has Gapkiller " and explain it to him , he would " oh ! awesome " , then i say " but i have to tell it's not being taken in the calculation , that means a less accuracy " , he will say " well , not that bad , i will turn it off when i do long playlists " , i imagine i go " mmm also i have to tell you the program doesn't calculate the milliseconds " , he will just beat me up now ..  ;D

 

[djsoft]

i had pointed over a bug  [ RB doesn't calculate milliseconds ] , and it's supposed to do so as he said , i proved it to him , then he said yes its a bug and it will be fixed , so its not a request its a bug that should be fixed for their own good , and for me, if they do't take this serious problem as serious , then its done for me ..

Yes, it can be considered as a bug. Actually the problem is deeper than I thought: playlists are saved in .m3u/.m3u8 format - that format can store track durations only in seconds. Milliseconds are lost when you save/load a playlist. Good news that we will switch RB to use XML playlists, those can store much more information and duration will be in milliseconds.

about the cost , how much would it cost to make a button that adds some milliseconds to the calculation as an offset ? ..

Adding new settings and options is not always good. If we add every option being asked for, the program will be bloated. Imagine you open Settings window and see 100 categories, each category has several subcategories and each subcategory has a number of options... It's a nightmare.
So only important and demanded options are added.

Regarding the Start Time calculation, I think we can add a menu option/button to perform a precise calculation. It will take into account as many factors as technically possible. Most likely (I don't promise) it will be added in the RadioBOSS 4.9.

 

[pety]

Good news that we will switch RB to use XML playlists, those can store much more information and duration will be in milliseconds.

Xml playlist sounds very good. What about diacritics (utf-8)?