You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By always keeping the entire current track in the buffer, recording the current track retroactively can be implemented very easily.
Simply start a new buffer when a new song title is received, and grow it until the next title or until a size/time limit is reached.
So a very long track (10min) could still be “recorded”, 10 minutes in, but a 2 hour DJ session would be a bit much. :)
At CD quality, this would take less than 10 MB of RAM.
From experience with my own scripts back in the day, I know that „keep last track” is useful too, but it needs to come with a “keep second to last track”, as many radio stations will quickly change the title for some in-track ads, and then the ads would be the “last track”.
Due to memory concerns that one could be option though, I guess.
I personally always kept it enabled even back in 2009 due to its high usefulness.
Another very important thing that StreamRipper did back then, was to keep a bit of the last track in the next one and vice versa. Because the title changes often were not very exact. It had a nice algorithm though that looked for the nearest quietest part within a range. That did not work on DJ sets though, so the “keep a bit of overlap” was still necessary. If you don’t already copied StreamRipper, I can only recommend looking at their algorithms, as they are well-polished and well-documented in the help. (No idea if SR still even exists.)
Right now, the fact that one can neither keep nor bookmark the current track is a bit unfortunate, because that is usually the one one is interested in.
(Anyway, the app is very nice. :)
The text was updated successfully, but these errors were encountered:
By always keeping the entire current track in the buffer, recording the current track retroactively can be implemented very easily.
Simply start a new buffer when a new song title is received, and grow it until the next title or until a size/time limit is reached.
So a very long track (10min) could still be “recorded”, 10 minutes in, but a 2 hour DJ session would be a bit much. :)
At CD quality, this would take less than 10 MB of RAM.
From experience with my own scripts back in the day, I know that „keep last track” is useful too, but it needs to come with a “keep second to last track”, as many radio stations will quickly change the title for some in-track ads, and then the ads would be the “last track”.
Due to memory concerns that one could be option though, I guess.
I personally always kept it enabled even back in 2009 due to its high usefulness.
Another very important thing that StreamRipper did back then, was to keep a bit of the last track in the next one and vice versa. Because the title changes often were not very exact. It had a nice algorithm though that looked for the nearest quietest part within a range. That did not work on DJ sets though, so the “keep a bit of overlap” was still necessary. If you don’t already copied StreamRipper, I can only recommend looking at their algorithms, as they are well-polished and well-documented in the help. (No idea if SR still even exists.)
Right now, the fact that one can neither keep nor bookmark the current track is a bit unfortunate, because that is usually the one one is interested in.
(Anyway, the app is very nice. :)
The text was updated successfully, but these errors were encountered: