PDA

View Full Version : Slimserver updating MP3 Tags - Is this feasible?



scalesr1
2005-06-16, 02:17
I am in the process of sorting out the tags on my music library in an effort
to remove inconsistencies and 'normalise' artists names etc.



I use Tag and Rename to perform the actual updates then re-scan the library
and measure the results by browsing my collection in the Slimserver Web
Interface.



It suddenly dawned on me that it would be a great if I could simply select a
given entity eg Artist for a given album and then jump right into some
mechanism that allowed me to change the tag data as required. This would
update the file and the Slimserver database and all would be wonderful.



Is this an idea for a plugin or even a 'feature' of some future release or
are there compelling arguments against it?



Fingers crossed!



Richard Scales

kdf
2005-06-16, 02:27
> Is this an idea for a plugin or even a 'feature' of some future release or
> are there compelling arguments against it?
>
This comes up every so often, and the policy is that slimserver is not planning
to write back to the files. There has always been rather intense opposition to
any plan that could have slimserver writing out to the audio files themselves.

-kdf

scalesr1
2005-06-16, 02:55
Yes, I can understand that - and of course - not all data contains tags -
hence it would need to cater for the various mechanisms of the various file
types.

Perhaps it would be possible to fire a link off to something like Tag and
Rename that then allowed one to edit the file(s) as required and then
perform a manual wipe cache/re-scan when ready?

This would reduce the amount of searching required in the two systems and
the primary focus could remain within the Slimserver environment.

Richard


-----Original Message-----
From: kdf [mailto:slim-mail (AT) deane-freeman (DOT) com]
Sent: 16 June 2005 10:27
To: Slim Devices Discussion
Subject: Re: [slim] Slimserver updating MP3 Tags - Is this feasible?


> Is this an idea for a plugin or even a 'feature' of some future release or
> are there compelling arguments against it?
>
This comes up every so often, and the policy is that slimserver is not
planning
to write back to the files. There has always been rather intense opposition
to
any plan that could have slimserver writing out to the audio files
themselves.

-kdf

kdf
2005-06-16, 03:08
Quoting Richard Scales <richard (AT) scalesweb (DOT) co.uk>:

> Yes, I can understand that - and of course - not all data contains tags -
> hence it would need to cater for the various mechanisms of the various file
> types.
>
> Perhaps it would be possible to fire a link off to something like Tag and
> Rename that then allowed one to edit the file(s) as required and then
> perform a manual wipe cache/re-scan when ready?
>
> This would reduce the amount of searching required in the two systems and
> the primary focus could remain within the Slimserver environment.

That's an interesting idea. I'm not sure what kind of communication tag &
rename might support, however.

What you can try is creating a playlist of any of he bad files that you find and
using that as your reference. You can also press and hold ADD button during
playback if you see a bad set of tags in the now playing display. This moves
the track from the current playlist to a special playlist called 'zapped.m3u',
intended to sort of quarantine bad files for review later. Would that be along
the lines of what you might want?

I use tag & rename myself, and I've found it to be fairly good for simply
browsing large groups of files and fixing along the way. Once you get the
initial work done, its easy to keep up with new tracks. Ripped tracks are
easy, some downloaded ones are a bit more effort.

-kdf

Howard Darwen
2005-06-16, 03:11
I don't think slim would provide the best interface for tagging to be
honest. Though I have the same issue in keeping the library in sync with the
tag data - i keep having to wipe cache as I add files all the time and make
minor tweaks to the existing tags (which can then flow through to the file
name/path). Once my library is more stable this will be a less frequesnt
activity, so am not so bothered about it.

One thing that may be useful to write though is ratings. It seems logical
that you'd want to do this while listening to the song. And storing it as
metadata is better than a separate library as it makes it portable between
devices.

h.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of Richard
Scales
Sent: 16 June 2005 10:56
To: 'Slim Devices Discussion'
Subject: RE: [slim] Slimserver updating MP3 Tags - Is this feasible?


Yes, I can understand that - and of course - not all data contains tags -
hence it would need to cater for the various mechanisms of the various file
types.

Perhaps it would be possible to fire a link off to something like Tag and
Rename that then allowed one to edit the file(s) as required and then
perform a manual wipe cache/re-scan when ready?

This would reduce the amount of searching required in the two systems and
the primary focus could remain within the Slimserver environment.

Richard


-----Original Message-----
From: kdf [mailto:slim-mail (AT) deane-freeman (DOT) com]
Sent: 16 June 2005 10:27
To: Slim Devices Discussion
Subject: Re: [slim] Slimserver updating MP3 Tags - Is this feasible?


> Is this an idea for a plugin or even a 'feature' of some future release or
> are there compelling arguments against it?
>
This comes up every so often, and the policy is that slimserver is not
planning
to write back to the files. There has always been rather intense opposition
to
any plan that could have slimserver writing out to the audio files
themselves.

-kdf

hashref
2006-05-10, 11:32
Tags can be nasty at times for me, too. What I'm considering on my end is creating a script that uses the zapped playlist as a mp3 tag update queue an set it up as a cron job...

I'm pretty good about storing my library in an <Artist>/<Album>/<Artist - track - title.mp3> format. Sometimes, its just <Artist>/<Artist - track - title.mp3> but for the most part the last string is the title of the song.

What I'm likely going to do is parse the zapped playlist and update the tags according to the directory structure and file naming convention every 24 hours. For really messy libraries I know this may not be a resolution, but in many cases this could work. After updating the tags I'll just empty the zapped playlist.

This approach should be better than running a job against my whole library every 24 hours.

Any thoughts on why this may or may not be a good approach?