Suche

[markah1]

Hi Mark,

I'm very sorry! I erroneously overwrote this article. That was not what I wanted. I appologize. I thought, I was going to answer this thread. I hope, the content that I could save is still meaningfull:

One small issue I've noted - Live365 treats the name of the radio station as the "Genre" in the tags, but when the name of the radio station starts with a non-alphabetical symbol (for example, the symbol for a musical note), then the genre folder is not created and music is not saved.  Please consider filtering out non-alphabetical symbols for the "Genre" folder the music is saved to.

Best regards
Thomas

[Thomas]

Hi Mark,

You're very welcome.

Thanks for the hint on this issue. Won't be a big thing to correct this with the next version. Eventually you could give me a URL because I didn't find an appropriate station at Live365.

Have a nice WE

Thomas

[markah1]

http://www.live365.com/stations/tparty is one of the stations with a musical note in its title (PartyCountry Radio).

By the way, although songs are now correctly labeled, how would I adjust the settings to avoid 9 seconds or so of the previous song being attached at the beginning, and 9 seconds being cut off at the end?  My settings are to select "Media Data Changes" "Search for end of song within these time intervals".  Would selecting "Duplicate this amount music" help?

Thanks again,

Mark

[Thomas]

Mark,

The general problem is that AOMrecord is hardly able to recognize where one song ends and the next one begins. If you select "Duplicate this amount of music" you may end up having the end of the last song in the next and vice versa. But this would give you a chance to cut off these parts with a wave editor.

I already thought about writing a simple editor to do just this. But until now the feedback to AOMrecord is far too little.

Sorry to say, but there is no other way than trying because this may differ from station to station.

HDH

Thomas

[markah1]

Since the end of the song is always marked by silence and this function works very well on AOMrecord, what we might need would be one of the following:

1. add to "search for end of song within these time intervals" a feature that a pause would then determine the end of the song (permitting all of AOM record's existing adjustments to recognize the pause); or

2. always have the end of the song always marked by a pause (permitting all of AOMrecord's existing adjustments to recognize the pause), but then have a slider to determine the media data within an adjustable period of up to 5 seconds before or after the silence.  

I think (2) may be the more elegant solution, but what do you think? Is this feasible for maybe two upgrades from now?

Regards,

Mark

[Thomas]

Mark,

The second solution reversed is what AOMrecord does. But what if it doesn't find a pause within this interval? That's what the overlapping part is good for.

Regards

Thomas

[markah1]

I understand Thomas.  So maybe the problem is to have the slider have the slider active only in one direction or the other.  I will try setting the slider to "0" before the change of media data, and "4" after the change of media data, and will see if this works with Live365.

Regards,

Mark

[Thomas]

Yes Mark, that's a good idea. Please inform us about the results.

Thank you

Thomas

[markah1]

Thomas,

I tried setting the slider to "0" before the change of media data, and "2", "4" and "5" after the change of media data. I found that each time I lengthened the interval, less music from the previous song is appended to the front of the file.  Since even a small amount of music can still be appended to the front of the file at 5 seconds, maybe this means that sometimes the change in media occurs more than 5 seconds before the end of the song?

If that is the case, perhaps the fix would be to have the slider extend for a longer interval, say, up to 15 seconds or so before/after the media change, so that the song ending can be detected properly?  If this works, it would be much better than having to edit the files.  (If you can make this change and need a tester, even if it's not soon, I'd be happy to help!)

Best regards,

Mark

[Thomas]

Mark,

Maybe that the change comes more than 5 seconds away from pause. I can't tell from here. In this case I don't think the pause recognition by media data change is the best way.

Because the internal wave buffer contains only 10 seconds in total a change in the interval size would mean a larger program adaption. I currently can't see a way to change this in the near future.

Best regards

Thomas

[markah1]

Thomas,

You are right, I have noticed that the media change comes a few seconds more away from the pause than 5 seconds.  

Would it work, and not overflow the internal wave buffer, if the slider adjustments went to 10 seconds on either side (before and after), and they were synchronized or locked together so that the total of the "before search" and "after search" is no more than 10 seconds?  

For example, the default setting is 5 seconds "before" and "after".  If the user moves the slider to 7.5 seconds "after", the "before" setting would automatically move to 2.5 seconds (so the total of "before" and "after" does not exceed 10 seconds).   And if the user moves the slider further, to 10 seconds "after", the "before" setting automatically moves to zero.

Alternatively, could the slider determine when the program looks for the media change, and so only the media change is stored by the program, not the music.  Perhaps if only the the media change is stored it would not require the internal wave buffer?

Regards,

Mark

[Thomas]

Mark,

That wouldn't work. Sorry. I'll have a look at the settings myself.

Are you a non-paying member at Live365 or do you have an account there?

Thomas

[markah1]

Thomas,

Yes, I have a paid account at Live365.

Mark

[Thomas]

Mark,

I had a look at some of these stations and found out that some send the media data about 20 seconds shifted. If I had to take this into account when calculation the pause recognition I needed a buffer for at least 40 seconds (20 in each direction), better 60. That's about 7 MB of buffer per minute that has to be processed. Processing means high CPU occupation that is taken away from other tasks. I'm not sure what this means to the other tasks that have to be done while recording.

Anyway, this would be a major design change which I cannot do in the near future. Maybe I'll come back to this but I can't promise right now.

Best regards

Thomas

[markah1]

Thank you Thomas.  I understand that a major design shift for this purpose only is not justified.

But would the program still need such a buffer if only the media tags were stored, and not the music (which would look for a pause in the current way)?

Best regards,

Mark