RadioBOSS 7.1 [beta]

At the beginning of the hour, the calculation appears correctly, ensuring it reaches the top of the hour. However, as it gets closer to the top of the hour, the feature completely disables itself.
After starting each track, it will re-evaluate the time stretch to make it more accurate. For best results, you should process the music tracks: https://www.djsoft.net/community/threads/precise-start-time-and-duration-calculation.4598/

If no changes were made to the playlist and the adjustment was already calculated, isn’t it strange that it disappears and then reappears with a different time stretch adjustmen
It can be due to gap killer (remove silence at the beginning and end) and "Trigger Mix" options, because of those exact track duration is not known. Please see the suggestion above for a solution.
 
Tested with Gap Killer disabled, and music tracks were already processed with Trim Silence. No Trigger Mix was enabled or processed.
 
Tested with Gap Killer disabled, and music tracks were already processed with Trim Silence. No Trigger Mix was enabled or processed.
On each track start, it recalculates the Start Time and Time Stretch. Do you see when the next hour starts, when the Time Stretch applied, is it correct (that is, it's at hh:00:00)?
You can see time stretch to "disappear" when it's not possible to adjust the speed to make it to the top of the hour. On your screenshots, it's already +3.5% while you have a limit of 4% - pretty close. If the new calculation is like +4.1% it will cancel the time stretch.
 
On each track start, it recalculates the Start Time and Time Stretch. Do you see when the next hour starts, when the Time Stretch applied, is it correct (that is, it's at hh:00:00)?
You can see time stretch to "disappear" when it's not possible to adjust the speed to make it to the top of the hour. On your screenshots, it's already +3.5% while you have a limit of 4% - pretty close. If the new calculation is like +4.1% it will cancel the time stretch.
Suggestion – In the future, would it be possible to add a feature under "Generate Playlist" that counts the exact number of tracks ending at the top of the hour? For example, if the playlist is generated in the middle of the hour, only the remaining tracks within that half-hour would be counted for the first hour.
 
Suggestion – In the future, would it be possible to add a feature under "Generate Playlist" that counts the exact number of tracks ending at the top of the hour? For example, if the playlist is generated in the middle of the hour, only the remaining tracks within that half-hour would be counted for the first hour.
I'm not sure I understood this, can you please provide some more details?

Maybe it will be possible to include Radioboss version in the scheduler window!!
How will it be useful there?
 
I'm not sure I understood this, can you please provide some more details?


How will it be useful there?

because in our radio we have a person who is dedicated exclusively to working with Ads Scheduler and he only has the Ads Scheduler icon on the desktop, so I never know which version he is using!
 
because in our radio we have a person who is dedicated exclusively to working with Ads Scheduler and he only has the Ads Scheduler icon on the desktop, so I never know which version he is using!
He can run RadioBOSS and check the version number there where it's needed. Ads Scheduler has an auto-generated build number which is long (about 20 digits).
 
I still have this problem sometimes, it doesn't happen all the time but it does happen. I set restrictions for music genre and language. In this screenshot you can see that neither of these two restrictions were respected.
1740855024931.png


A few minutes later it happened again
1740855915093.png
 
Last edited:
On each track start, it recalculates the Start Time and Time Stretch. Do you see when the next hour starts, when the Time Stretch applied, is it correct (that is, it's at hh:00:00)?
You can see time stretch to "disappear" when it's not possible to adjust the speed to make it to the top of the hour. On your screenshots, it's already +3.5% while you have a limit of 4% - pretty close. If the new calculation is like +4.1% it will cancel the time stretch.
After testing with different limits such as 7, 10, and 15 %, it still doesn’t end at the top of the hour. The test was conducted using two files (Music and Jingles) with “Treat as a music track” enabled and crossfade applied. The playlist was generated with trim silence, normalize tracks, and detect BPM processing.
 
I'm not sure I understood this, can you please provide some more details?

I was thinking about whether this makes sense or not. My suggestion is to have an option in the playlist generator that selects and fits songs exactly within an hour, regardless of whether trim silence and other features are enabled.

For example, if I create a playlist at 00:30:00, there would only be 30 minutes left until the top of the hour. The system would then select tracks that fit precisely within that remaining time. Once the next hour starts, it would pick tracks that fit exactly into the full 60-minute window.

This feature would be especially useful for automated radio stations, as the current time-stretching feature is the closest alternative. However, the way it works now makes it unlikely that a song will end exactly at the top of the hour.

It’s just a suggestion, but I think it could improve accuracy in scheduling!
 
Last edited:
Can’t you put the same RadioBOSS version number?
This looks like a very situation-specific request, I'm not sure many other users need that version number there.

I still have this problem sometimes, it doesn't happen all the time but it does happen. I set restrictions for music genre and language. In this screenshot you can see that neither of these two restrictions were respected.

A few minutes later it happened again
The Playlist Generator checks the immediate track, it does not ignore the jingles/ids/etc. in between. So technically speaking those music tracks do not follow each other, because it's track-id-track.
 
After testing with different limits such as 7, 10, and 15 %, it still doesn’t end at the top of the hour. The test was conducted using two files (Music and Jingles) with “Treat as a music track” enabled and crossfade applied. The playlist was generated with trim silence, normalize tracks, and detect BPM processing.
Can you please specify what happened at the end of the hour? Because it should be one of the two scenarios:
  • The Time Stretch properly applied and the last track ended at the hour end (actually it calculates so that start of the first track of the next hour is at hh:00:00).
  • The Time Stretch can not be applied because required speed adjustment is not in range of the allowed speed change, and tracks play as they are.
If you see the time stretch applied, but last track ends at a wrong time, this looks like a bug. I think a screenshot of the main RadioBOSS window will help understand better. Please note that if there's any manual intervention (moving/adding/deleting/seeking tracks or something) - then time stretch will probably not work as expected.

I was thinking about whether this makes sense or not. My suggestion is to have an option in the playlist generator that selects and fits songs exactly within an hour, regardless of whether trim silence and other features are enabled.
It already tries to create playlist as closer to the set duration as it can (it re-rolls the last 1-2 tracks to better match the desired duration). If you have Trim Silence and other features enabled, then the tracks have to be pre-processed in the Music Library to take that into account (making Playlist Generator do this job will result in way too much time needed to create a playlist).

For example, if I create a playlist at 00:30:00, there would only be 30 minutes left until the top of the hour. The system would then select tracks that fit precisely within that remaining time. Once the next hour starts, it would pick tracks that fit exactly into the full 60-minute window.
I think you should take a look at the Sweepers feature: https://manual.djsoft.net/radioboss/en/sweepers.htm
And the new Time Stretch feature.

This feature would be especially useful for automated radio stations, as the current time-stretching feature is the closest alternative. However, the way it works now makes it unlikely that a song will end exactly at the top of the hour.
It's supposed to adjust the speed so that the tracks end exactly at hour end.
 
The Playlist Generator checks the immediate track, it does not ignore the jingles/ids/etc. in between. So technically speaking those music tracks do not follow each other, because it's track-id-track.
any solution for this case? is there any option added to ignore the identifiers and only work with the music?
or perhaps an option to ignore certain file types.
 
Last edited:
I love the ability to rewind and fast forward with hotkeys, as I had requested before. However, could the hotkeys change to something a bit harder to press such as control comma for reward and control period for fast forward? This feels more consistent, but most of all, control+left and control+right arrow are screen reader commands to read the previous and next word of the current edit field you're in. So while you could make sure that those keys aren't used in radioboss if the cursor is focused in an edit field, it may be less trouble to change the key assignments. Either would prevent awkward mistakes on air while simply trying to review information
 
Can you please specify what happened at the end of the hour? Because it should be one of the two scenarios:
  • The Time Stretch properly applied and the last track ended at the hour end (actually it calculates so that start of the first track of the next hour is at hh:00:00).
  • The Time Stretch can not be applied because required speed adjustment is not in range of the allowed speed change, and tracks play as they are.
If you see the time stretch applied, but last track ends at a wrong time, this looks like a bug. I think a screenshot of the main RadioBOSS window will help understand better. Please note that if there's any manual intervention (moving/adding/deleting/seeking tracks or something) - then time stretch will probably not work as expected.
I noticed that while the system indicates that the last track will end exactly at the top of the hour, allowing the next hour’s first track to start at 00:00:00, the last track actually ends earlier. I was wondering if the issue is related to the trim silence process not being accounted for in the calculation. I reprocessed the trim silence and tried again, but the result remained the same.

In many cases, the Time Stretch feature does not apply as expected, even though it shows that the adjustment is set for the last track.
Another issue I observed is with the speed adjustment: for example, the last two tracks of the final hour were initially calculated at +5.3% and +7.3%, with the next hour’s first track scheduled to start at 00:00:00. However, as soon as the second-to-last track finished, the stretch adjustment for the final track suddenly changed from +7.3% to +10.8%, causing the track to speed up but still ending earlier than indicated.

No manual adjustments were made to the playlist after everything was loaded.
 
Last edited by a moderator:
any solution for this case? is there any option added to ignore the identifiers and only work with the music?
or perhaps an option to ignore certain file types.
We'll do something about it, e.g. an option for the category like "Do not take into account for constraints" which you can enable for IDs and other categories.

However, could the hotkeys change to something a bit harder to press such as control comma for reward and control period for fast forward?
Yes, makes sense as Ctrl+Arrow is pretty common for other tasks. We'll change it to Ctrl+comma/period.

I was wondering if the issue is related to the trim silence process not being accounted for in the calculation. I reprocessed the trim silence and tried again, but the result remained the same.
It can be the mix point (Trigger mix at option) so you should process that also.

In many cases, the Time Stretch feature does not apply as expected, even though it shows that the adjustment is set for the last track.
Do you mean it shows certain percentage but there's no actual speed change? If so, please check the logs, are there any error messages about it not being able to apply speed change?

However, as soon as the second-to-last track finished, the stretch adjustment for the final track suddenly changed from +7.3% to +10.8%, causing the track to speed up but still ending earlier than indicated.
On each track start, it will reevaluate the percentage so ensure hour ends when it's supposed to. We'll check it if there's something wrong.
 
Back
Top