[mb-users] Re: what's with the crusade against adding legit NATs?

[Björn Krombholz]

On 8/29/06, Lauri Watts <krazykiwi at gmail.com> wrote:
> On 8/29/06, Chris Bransden <chris at whenironsattack.com> wrote:
> > either way, it's still a single, not a NAT.
>
> And either way, it's not the topic of contention, we've all the rest
> of us moved on past that.

Why? It's part of the problem.

> The debate is: "do we want to be adding data to the database  that is
> completely correct today will need to be removed in the future".

Can we really avoid it? In most cases, one doesn't know whether a
track will or will not be released as part of a real release. IMO NATs
are containers to hold tracks you can't put anywhere else.

Adding something like DDTS as a NAT would be as good as adding the
unreleased album which can be fixed later, when the later release
differs.

But for this particular example, the common understanding of the
"single" concepts fits pretty well. It is related to an album release,
it comes with it's own packaging, it even has a cover. It's not
different than 90% of the other singles, except that it is released on
a different medium, which is fine, as we have to deal with new media
all the time.

On the other hand, there are a lot of NATs that are just random
tracks. A lot of those are net releases (e.g. the OCRemix tracks).I'd
propose the expansion of the flexibility of NATs for those tracks by
adding an additional text field, which allows a description of the
track. Today a lot of NATs have only a title and nothing else, which
is bad, because often nobody can tell whether the track really exists
or not.


The implementation of this idea could be done without any database
schema changes. Instead NATs could be handled as one-track-albums
internally. The user will never see that it's an album, except that he
will be able to add an annotation and a release event to the track.



#Fuchs