Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_dsp_continuator (Read 270925 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_dsp_continuator

Reply #100
Quote
Who cares if someone else's formatting doesn't support your tags? You? You are free to hack at the formatting, and you'll have the freedom of not being forced to change your tags.
[a href="index.php?act=findpost&pid=296801"][{POST_SNAPBACK}][/a]

FYI, there are many fb2k users, who do know almost nothing about TAGZ-hacking and rely on ready-for-use public formatting strings. There are also many people who aren't very familiar with the masstagger for the same reasons.

Not every fb2k-user is a programmer/scripter. Do you propose to not care about those? Also, even tagz-coders may prefer a situation where "it just works" instead of them having to hack the formatting, because of incompatibility caused by an ambigious tag-standard.

- Lyx
I am arrogant and I can afford it because I deliver.

foo_dsp_continuator

Reply #101
Customization is good, but it's important to have sane default values.

Formatting string coders can rely upon the default values of foo_dsp_continuator_tagz if they want.

I didn't say that everything should be barebone, with the burden of formatting being pushed on to potential newbies.

foo_dsp_continuator

Reply #102
Quote
Customization is good, but it's important to have sane default values.
[a href="index.php?act=findpost&pid=296806"][{POST_SNAPBACK}][/a]

Can you name a situation, where your proposed customization is useful? Something which outweigths the mentioned disadvantages?

Also, making it configurable adds some more options to the continuator preferences. As mentioned somewhere else, every unneeded option is a flaw, not a feature - so is there some benefit which outweights the added complexity?

- Lyx
I am arrogant and I can afford it because I deliver.

 

foo_dsp_continuator

Reply #103
*sigh*

I don't want to use CONTINUATOR. I want to use FADING or something else which *I* think is approriate. I thought I'd already mentioned that TAGZ can be useful for me in this case.

You might have noticed before that I regard customizability as a strong bonus, not as a flaw. I don't think I'll change my mind any time soon.

foo_dsp_continuator

Reply #104
Quote
I don't want to use CONTINUATOR. I want to use FADING or something else which *I* think is approriate.
[a href="index.php?act=findpost&pid=296808"][{POST_SNAPBACK}][/a]

In other words, you propose to make continuator-preferences more complex and introduce the risk of incompatibility, just because you or someone else may not like the NAME of the tag?

Sounds like it could be a better idea to discuss and agree on a tag-name which is okay to most instead.

- Lyx
I am arrogant and I can afford it because I deliver.

foo_dsp_continuator

Reply #105
"Come here. Knock knock."
"Who's there?"
"Control freak. Now you say, 'Control freak who?'"

Well, yes.

OK, so what will it be? CONTINUATOR_MODE CONTINUATOR_FADELENGTH, akin to REPLAYGAIN? FADING::MODE FADING::LENGTH, or CONTINUATOR.MODE CONTINUATOR.FADES making use of Vorbis comments?

foo_dsp_continuator

Reply #106
Quote
"Come here. Knock knock."
"Who's there?"
"Control freak. Now you say, 'Control freak who?'"

Some control and "consensus" is necessary to allow interoperability and compatibility. You wouldn't be able to post on this forum, without an agreement how webpages are described. Replaygain would be very frustrating without an agreed scheme. People wouldn't be able to communicate efficiently without established languages. Playcounter isn't supported in most formatting-schemes because of its ambigious format. If all those folks involved in the mentioned agreements are control-freaks is a matter of opinion.

Quote
OK, so what will it be? CONTINUATOR_MODE CONTINUATOR_FADELENGTH, akin to REPLAYGAIN? FADING::MODE FADING::LENGTH, or CONTINUATOR.MODE CONTINUATOR.FADES making use of Vorbis comments?
[a href="index.php?act=findpost&pid=296817"][{POST_SNAPBACK}][/a]

Why create multiple tags for it? I mean, as shown in my proposal, one tag is enough to implement it. It could even be extended if necessary in the future, because the options are just seperated with commas - so as long as the order remains unchanged, it can be extended in the future.

- Lyx
I am arrogant and I can afford it because I deliver.

foo_dsp_continuator

Reply #107
Quote
You wouldn't be able to post on this forum, without an agreement how webpages are described.

Bad analogy. HTML is a machine language. Tags are for natural languages.

Quote
Playcounter isn't supported in most formatting-schemes because of its ambigious format.

Playcounter is probably unsupported because it's unpopular; plain and simple.

Quote
Why create multiple tags for it? I mean, as shown in my proposal, one tag is enough to implement it.[a href="index.php?act=findpost&pid=296821"][{POST_SNAPBACK}][/a]

To better describe the contents. Would you want your REPLAYGAIN tags to contain +11,0.49385930,+10,0.58303389? (edit: Plus, it will work nicely with foo_quicktag, I think.)

The principle here is, "One tag, for one thing." We want things to be userfriendly, and consistency is useful, isn't it?

PS. I was implying that *I* was a control freak when it comes to tagging.

foo_dsp_continuator

Reply #108
Quote
In other words, you propose to make continuator-preferences more complex and introduce the risk of incompatibility, just because you or someone else may not like the NAME of the tag?[a href="index.php?act=findpost&pid=296813"][{POST_SNAPBACK}][/a]

Let's look at this again.

How bad is complexity? Unnecessary complexity is bad, I agree.  Nevertheless, complexity can be ignored. If you don't understand it, you don't need to touch it. Everything in foobar2000 is pretty straight-forward, if you know what they mean, and nobody forces you to understand it.

Now, about the risk of incompatibility. How big is it?

If you assume that TAGZ writers will want to write for the largest audience, they'll write formatting for foo_dsp_continuator_tagz's default settings.

People who don't know how to use TAGZ will just use the defaults, and they'll be fine.

People who do know how to use TAGZ will be able to deal with incompatibilty. They have the tools, and they'll have the knowledge. So where's the risk?

foo_dsp_continuator

Reply #109
Quote
Quote
In other words, you propose to make continuator-preferences more complex and introduce the risk of incompatibility, just because you or someone else may not like the NAME of the tag?[a href="index.php?act=findpost&pid=296813"][{POST_SNAPBACK}][/a]

Let's look at this again.

How bad is complexity? Unnecessary complexity is bad, I agree.  Nevertheless, complexity can be ignored. If you don't understand it, you don't need to touch it. Everything in foobar2000 is pretty straight-forward, if you know what they mean, and nobody forces you to understand it.

Now, about the risk of incompatibility. How big is it?

If you assume that TAGZ writers will want to write for the largest audience, they'll write formatting for foo_dsp_continuator_tagz's default settings.

People who don't know how to use TAGZ will just use the defaults, and they'll be fine.

People who do know how to use TAGZ will be able to deal with incompatibilty. They have the tools, and they'll have the knowledge. So where's the risk?
[a href="index.php?act=findpost&pid=296992"][{POST_SNAPBACK}][/a]


Personally, if I were to choose between the formatting options, I would go with Lyx's option.  It seems silly to have not one but multiple tags--and be continuously adding in new values as foo_continuator adds new functionalities.  Keeping everything relevant to continuator inside one tag specifically designed *for* continuator makes much more sense than having 10 extra tags attached to each of thousands of mp3's to fill the required information for *one* plugin.

On a side note though, neither option really appeals to my personal collection.  I'm one of those people who keeps the tags on my mp3s limited to:
artist;title;album;tracknumber;date;genre;album artist
What I would be very much interested in is some kind of designation for a particular playlist to be played in a particular way.  IE, that mix playlist/tab you made for a party should be able to be set to "crossfade for 10 seconds" and any mp3s contained within would be played accordingly.  While I see the reason and necessity for a tag designating the function of each mp3 as it's played, I think the *vast* majority of users would be much happier being able to create a playlist out of currently existing mp3s and play them in a specific manner without updating the actual tag-data of each mp3 (which may be singles from dozens of albums).  Then, when I close foobar and open it up again another week, foobar still remembers how to crossfade for the playlist I've created.  This is especially useful to those who play mp3's across a network and don't have write-access to write new tag data, but want to quickly and easily assemble playlists that continuate in a specific manner.


foo_dsp_continuator

Reply #111
Quote
On a side note though, neither option really appeals to my personal collection.  I'm one of those people who keeps the tags on my mp3s limited to:
artist;title;album;tracknumber;date;genre;album artist
What I would be very much interested in is some kind of designation for a particular playlist to be played in a particular way.  IE, that mix playlist/tab you made for a party should be able to be set to "crossfade for 10 seconds" and any mp3s contained within would be played accordingly.  While I see the reason and necessity for a tag designating the function of each mp3 as it's played, I think the *vast* majority of users would be much happier being able to create a playlist out of currently existing mp3s and play them in a specific manner without updating the actual tag-data of each mp3 (which may be singles from dozens of albums).  Then, when I close foobar and open it up again another week, foobar still remembers how to crossfade for the playlist I've created.  This is especially useful to those who play mp3's across a network and don't have write-access to write new tag data, but want to quickly and easily assemble playlists that continuate in a specific manner.
[a href="index.php?act=findpost&pid=296996"][{POST_SNAPBACK}][/a]

I agree, however, that info still needs to be stored somewhere. The playlist-files themselves obviously are a no-no for that purpose(to not break their format). DB-only entries would be nice, but fb2k doesn't support that yet. That leaves us either with a seperate config-file for continuator, or plain simple tags. Tags have the advantage, that a playlist-formatting can make use of that info (after all, when creating such a playlist which you describe, it would be useful to *see* which tracks have which settings.)

- Lyx
I am arrogant and I can afford it because I deliver.

foo_dsp_continuator

Reply #112
Quote
I agree, however, that info still needs to be stored somewhere. The playlist-files themselves obviously are a no-no for that purpose(to not break their format). DB-only entries would be nice, but fb2k doesn't support that yet. That leaves us either with a seperate config-file for continuator, or plain simple tags. Tags have the advantage, that a playlist-formatting can make use of that info (after all, when creating such a playlist which you describe, it would be useful to *see* which tracks have which settings.)

- Lyx
[a href="index.php?act=findpost&pid=297044"][{POST_SNAPBACK}][/a]


Not really;  For example, all the configuration info for foo_pod is stored in foobar2000.cfg (iPod (foo_pod) for playlist name, how to send data, etc).  All you'd need to do is maintain a small list of the current playlists and their behaviors, just slapped right into foobar2000.cfg and associated with foo_continuator


foo_dsp_continuator

Reply #114
Hi guys,

i've uploaded continuator version 0.3.0, which adds the following new features:

- control through CONTINUATOR tag (see below)
- additional delay dependant on speed of volume drop, to give tracks with sudden ends some 'air', before the next track starts (currently not configurable)
- new menu items 'Settings...' and 'Override settings by CONTINUATOR-tag'


CONTINUATOR tag:

i chose to support three tag values with optional parameter

Code: [Select]
tag value      | description
---------------|------------------------------------------------------------------
overlap[,n]    | track overlapping dependant on volume,
               | optional parameter n: threshold, rms drop in dB (range 0-100)
               |
crossfade[,t]  | track crossfading,
               | optional parameter t: time in ms (range 0-'Maximum overlap length')
               |
off            | do nothing

notes:

- if you omit the parameter, the value from the settings is used
- case doesn't matter
- crossfade curves are currently not configurable


examples:

gap killing:
overlap,60

normal operation:
overlap,6
overlap,12

10 sec crossfade:
crossfade,10000


Enjoy!

foo_dsp_continuator

Reply #115
Excellent !!    I'll play with that new version during my soon-to-come live broadcast and I'll send you my feedback...

foo_dsp_continuator

Reply #116
Great, Cpt. Footure,

just one thing: The 'Toggle State' command item now doesn't show a checkbox next to it when it is used in a menu.

And one suggestion: Nice of you to implement the extra tag info, but I would strongly recommend that you concentrate on automated intelligence instead, as most of us have music libraries sufficiently large that the thought of manually tagging thousands of songs with crossfade data is unthinkable. IMHO, of course.   

Cheers,

C

foo_dsp_continuator

Reply #117
Quote
just one thing: The 'Toggle State' command item now doesn't show a checkbox next to it when it is used in a menu.
The checkmark is next to the current state instead.

Quote
And one suggestion: Nice of you to implement the extra tag info, but I would strongly recommend that you concentrate on automated intelligence instead, as most of us have music libraries sufficiently large that the thought of manually tagging thousands of songs with crossfade data is unthinkable. IMHO, of course.
I agree. Do you have any concrete suggestions as to where the intelligence should be amplified?

Bye

foo_dsp_continuator

Reply #118
Quote
Quote
just one thing: The 'Toggle State' command item now doesn't show a checkbox next to it when it is used in a menu.
The checkmark is next to the current state instead.


Yeah, but I've just got a 'Toggle state' item in my systray menu, and now I can't tell at a glance whether it's enabled or not. Seems silly to add Enable/Disable menu items just for monitoring purposes. 

Quote
Quote
And one suggestion: Nice of you to implement the extra tag info, but I would strongly recommend that you concentrate on automated intelligence instead, as most of us have music libraries sufficiently large that the thought of manually tagging thousands of songs with crossfade data is unthinkable. IMHO, of course.
I agree. Do you have any concrete suggestions as to where the intelligence should be amplified?


Basically, the only real problem I have is with tracks that come from live albums or continuous-flow compilations. Because they carry on loud all the way to the end, you get a really ugly sudden stop as the next track slams in. I think it would be good to have a way of automatically determining whether a track is still above the volume threshold within (say) a few ms of the end of the file, and in such cases force a fade out starting a pre-determined number of seconds before the end. The incoming track could then use this forced fade to determine its inpoint.

This would be my number 1 priority improvement.

Great plug-in though; good to know it's still in active development. Remember this was the plug-in that ultimately convinced to make the switch over from Winamp.

Take care,

C

foo_dsp_continuator

Reply #119
Quote
Yeah, but I've just got a 'Toggle state' item in my systray menu, and now I can't tell at a glance whether it's enabled or not. Seems silly to add Enable/Disable menu items just for monitoring purposes. 
I see, you'll get your checkmark back.

Quote
Basically, the only real problem I have is with tracks that come from live albums or continuous-flow compilations. Because they carry on loud all the way to the end, you get a really ugly sudden stop as the next track slams in. I think it would be good to have a way of automatically determining whether a track is still above the volume threshold within (say) a few ms of the end of the file, and in such cases force a fade out starting a pre-determined number of seconds before the end. The incoming track could then use this forced fade to determine its inpoint.

This would be my number 1 priority improvement.

Great plug-in though; good to know it's still in active development. Remember this was the plug-in that ultimately convinced to make the switch over from Winamp.
Ok, consider it done. We don't want to lose you again to 'The Dark Side' 

foo_dsp_continuator

Reply #120
Actually I did the broadcast in a hurry so I hadn't had the time to plan which tracks to play. I just used the standard behaviours, without the new tagging options. However, the plugin seems to be stabler than ever  I'll let you know if I find something more to add !

foo_dsp_continuator

Reply #121
Hi guys,

i've uploaded continuator version 0.3.5, which adds the following new features:

- the two modes overlap and crossfade are now selectable from the UI
- configurable fade-out and fade-in curves
- fade length independent from crossfade resp. overlap length
- option to apply fade-out only when there's audio up to the end of the track ie. when the rms level doesn't drop below the threshold setting
- toggle checkmark for Carlos

Enjoy!

 

foo_dsp_continuator

Reply #122
Wow, this looks excellent, will test it soon, many thanks!

foo_dsp_continuator

Reply #123
You're a legend, Cap.


Off to try it now...

foo_dsp_continuator

Reply #124
Guys?

No bugs found?
No comments?
No suggestions?
Speechless regarding the extraordinary features and outstanding stability?

Or busy testing 0.9?