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.

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.

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

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?

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 (kjoonlee @ May 11 2005, 02:20 PM)

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?

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.

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?

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?

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?

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?

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 artistWhat 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.

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 artistWhat 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.

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.)

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

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

- 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'

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.

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 (CarlosTheTackle @ Jun 13 2005, 09:59 AM)

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?

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 (Cpt. Footure @ Jun 14 2005, 10:55 PM)

QUOTE (CarlosTheTackle @ Jun 13 2005, 09:59 AM)

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.

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 (CarlosTheTackle @ Jun 14 2005, 01:14 PM)

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'

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 !

- 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