Abstract idea of Song instead of pure file management

[Cody Christensen]

On Friday 05 December 2008 6:44:59 am Jeff Mitchell wrote:
> Cody Christensen wrote:
> > I'm sorry to jump in on a thread that appears almost dead and I won't
> > claim to comprehend every one of the posts as some of them are complex
> > and detailed but...
> > 	I would like to bring up my idea that I discussed briefly on this list
> > earlier this year.  That is the idea of a spell checker type interface. 
> > I believe that Amarok 2 will ship with a helper program used for the
> > advanced AFT (sorry don't remember exactly what it is called) What if the
> > feature was implemented so that only the dead sure entries were
> > automatically associated and any other "Advanced" association was handled
> > through an extention to the helper program that already exists.
>
> I don't quite follow what you're saying, but I don't quite think you
> understand what AFT does.  AFT is used to track files (not songs per se)
> so that as you move them around, they remain playable within Amarok (as
> well as updating the statistics, lyrics, etc. associated with that file).
>
> This is separate and complementary to the idea of song correlation,
> where the primary features are to identify duplicate tracks (possibly at
> different bitrates/formats) so that algorithmically the best one is
> always played (for instance), and so that statistics/lyrics/etc. can be
> kept per song, regardless of which actual file is in the statistics
> database.
>
> This is complementary to AFT but can't necessarily replace it, as basic
> non-embedded AFT does not require any interaction from the user at all.
>  Interaction is only required if they want to have more robust tracking
> that does not have some of the corner cases associated with the
> non-embedded kind.  Song correlation will always require interaction*,
> and there are also people who will not want Amarok to perform this
> correlation, so cannot be an "enabled by default" thing.  In addition,
> although some functionality could be augmented by both,  there is some
> completely different functionality: song correlation is nice, but if you
> move the files around, the playlist still won't be able to play them
> unless you have AFT to tell it where the files are now located.
>
> --Jeff
>
> *I say always because all of the proposals so far require a (slow)
> scanning process of the entire file, possibly followed by a rewrite of
> the entire file if it is storing information in tags.  This is too slow
> to be put upon every user during a scan of their library (even if it is
> only slow the first time), so will require users to explicitly enable it
> (either through adding the information with an external program, or
> perhaps with a script within the Amarok UI).
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok

	Sorry if I was not clear. The only reason I brought up the more robust AFT is 
that I remember you saying that there would be an external program shipped 
for the purpose of AFT and I figured it could be a multipurpose program.  
When they start that external "helper" program they could have the choice of 
scanning the files and creating the necessary data for the robust AFT and as 
a SEPARATE option they can perform the fuzzy song corelation that would also 
require interaction.
	The original idea would still be implemented. If I understood the thread 
correctly I think that would mean that only the exactly matching tags would 
automatically be corralated together. Then the fuzzy search (that requires 
interaction) could be started through the "helper" program like the AFT is.
	So I hope that cleared it up. It had nothing to do with AFT besides the fact 
that it could be part of the same "helper" program.  Let me know if you are 
still confused.

-- 






							-Cody Christensen