[PATCH] ReplayGain tags

[Alex Merry]

On Sunday 11 January 2009 10:08:22 you wrote:
> The first is that, perhaps, from the general view of database design, it
> would be better to put replayGain stuff in another table, referenced by
> foreign key.

What Seb said.  For a value that is (a) different for every track and (b) each 
track only has one, an extra table doesn't save any storage and just 
introduces JOIN overhead.

>
> > I incremented the DB_VERSION to 2 and made DatabaseUpdater::update()
> > modify the tracks table if the version of the existing database was 1. 
> > Also, it does a full collection rescan (since an incremental scan only
> > checks for changed files - there is no "look for new metadata in all the
> > old files without clearing out the database" mode for collectionscanner).
>
> I don't think this would be a nice behavior. I'd make it pop out a message
> saying something in lines of "Amarok needs more information from your music
> files, please rescan your collection to enable shiny new features".

Which is why I'd like a "find new metadata" mode for amarokcollectionscanner.  
Bugging the user about something that should just happen is also not good, 
IMHO.  I'll have a look at how easy this would be to implement.

>
> Also, I am not exactly sure the update logic is correct, because i can't
> fully understand the old logic (why was there dbVersion > DB_VERSION?).

The old logic didn't make any sense - in addition to having the DB_VERSION 
check the wrong way round, it wouldn't have DROPed the tables before CREATEing 
new ones, only cleared out their contents.  Hence my upgrade logic (since 
adding two new fields doesn't require dropping the existing database anyway).

Not that it ever mattered before: Amarok 2.0 was released with database 
version 1 and couldn't have conflicted with Amarok 1.x, since the database 
type changed.  Before 2.0, asking devs to delete their old database when it 
changed was fine.

>
> As a minor rant, I'd make qreal variables initialized with 0.0 instead of
> 0.

OK.

Alex



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20090111/7df4b10f/attachment.sig