beets
beets copied to clipboard
beetbox
Attachments to items and albums
This issue was automatically migrated from Google Code. Original author: adrian.sampson (November 17, 2010 23:05:05) Original issue: https://github.com/google-code-export/beets/issues/109
I wish to add my vote to this, I am a FLAC (100% log & CUE) man, and until I can move log & CUE files with the beets import, I am unable to use beets (at least, without manually moving those files after import).
However, a suggestion on google code worries me slightly. No changes should ever be made to log files, the point of them is to be accurate at the time of the rip. That means they should never be changed, not even if file names change later on.
So making changes to log & CUE sheets aren't an issue for me, nor is storing them in the database. I simply would love to move them along with the rest of the files, upon import. With options would be a great bonus.
Many thanks.
If there is any way I can help, please let me know. I'm not a Python developer, but if there's anything I can do to help, I will try my very best.
If you do have extra time, it can never hurt to have some help thinking though exactly how the feature will work in the form of a set of requirements. Something like the following process would be helpful:
- Brainstorm a list of all the possible things a user—not just yourself—might want to do with an attachments-like feature.
- Prioritize this list roughly. Draw a line above which things seem important enough to address and below which the use cases are more optional.
- Make a second list describing the set of concrete bits of functionality that beets would need to cover all the use cases.
- Finally, translate these features into detailed designs for the command-line flags, an config options that form the user interface to the functionality. Write proto-documentation for these notional options to describe what they do.
It's not coding, but requirements design like this can sometimes be more helpful than the code itself! Let me know if you're interested.
I'm very interested, it'll help me get on my feet with this stuff. A bit of the language you've used is new to me, being a web designer/HTML/CSS monkey!
What are command-line flags? Proto-documentation? And I'll probably need a it of help with "config options that form the user interface to the functionality"... other than that, I get the gist of what you're asking.
I will try my very best to help you out! :-)
Great! I'm happy to clarify; sorry for the use of jargon.
command-line flags: Here I mean the relevant commands and options for the beet CLI program. For example, might we want a beet attach command for adding new files to an album?
config options: Like these.
proto-documentation: Here I was just suggesting that we write up documentation for any commands or config options we invent even though they don't yet exist. Writing documentation before code can help clarify what we want the code to do.
Here's a wiki page to start taking notes in.
Thank you very much and sorry for the lack of understanding. I appreciate your clarification. I'll get cracking on that and will hopefully help out when I get a spare five minutes. Thank you! :-)
Little bit of work on the use cases, not a definitive list and will add to it in the coming few days.
Looking good! This is a great start.
I wanted to make one comment on how things are shaping up here: I see the "core" functionality of attachments as being separate from anything we add for dealing with cue files (splitting/joining album FLACs, etc.). The former will become part of beets core; the latter will be a plugin (or possibly multiple plugins) that uses the attachments functionality.
Totally agree with your above sentiment. It makes sense for the attachments stuff to be core with further cue sheet functionality offered via plugins. I will endeavor to write a little more later today if I get a chance.
Per my duplicate issue identified in the previous post, I propose that the mechanism be flexible to allow users to specify arbitrary filetypes that could be attached whenever an album is copied or moved. For instance, filetypes could be arbitrarily specified in config.yaml as follows:
attachfiletypes: jpg png log cue nfo m3u
Sounds good to me. I'm sure that's not meant to be a definitive list but I'd like to toss "pdf" into the mix too! :-)
Want to add my vote for this option. I have found recently I am spending a lot of time going through each processed album and moving the extra files from a CD rip (log, cue, m3u, txt, jpg sometimes in a separate directory), to a directory on my collection. This would be a great assett to get this implemented.
I would like to suggest the option of not only being able to add specific file types, but the option of adding everything. Maybe
attachfiletypes: *
I would like to see it remove the directory also on a move, but that is not a major thing.
thanks
I would also vote for attachfiletypes: * because it's a usual case when you have directory name 'Artworks' with full cd scans. Actually there's nice guides on what.cd how a scene organizes music album :) would be handy I think.
Has anyone got any workarounds? I have many folders with odd files I need to move to my music collection and looking for some time saving. :)
No workarounds from me, it's a chore but as soon as I run "beet import" I drag and drop the attachments into the same folder as the music. However, this isn't ideal because it's not going to be associated with the music in the beets database. A couple of days ago I added a section on how "beet attach" should handle these cases to the wiki page...
https://github.com/sampsyo/beets/wiki/Attachments#beets-functionality
+1 for this issue, i discovered beets today and very anxious to start using it but have thousands of file (lyrics, cue etc) associated with my thousands of albums and dont want to loose it..any update on this?
best
Z
Thanks for your vote of confidence, but we're still working on it. If you'd like to contribute, the wiki for the use cases would be a great place to start.
Thx!
As requested I added a non technical (i cant code at all unfortunately :) ) use case (see also pasted below at the end of the post):
I would also like to take the time to thank you alot for beets, i just discovered it and it looks amazing. I cant code but would love to continue and help out and contribute in other areas needed.
A quick related question. since it will take some time (any idea how much very roughly..weeks. months?) to implement the move associated files, how do you recommend i proceed with my use? im really dying to start using beets but i am dependent on associated files in my library (artist images, album images, lyrics files etc). if i import currently all my files into beets i will obviously loose these files. since i have thousands of entry's in my music library i cant manually move the associated files. should i just wait for that move feature or is there another clever way of doing this?
Thx
Z
WIKI entry: Plugin for moving additional files (like cuesheets, scans etc.) into library on import This would work in the following way: in the config file you would enable the "move additional files" plugin (maybe "filemove" plugin for short) and configure it based on file type. Also it would be very useful to define the level of files, that is the album folder level (move the album folder files to the associated $album folder and the artist level (move the files found in the artist root folder to the $albumartist/$artist) folder. Also a move/copy option and a delete previous/empty folder could also be great in terms of the config file i assume it would look like this plugins: bpd fetchart embedart replaygain mpdupdate fromfilename filemove filemove: type: *.jpg *.png *.lyric *.lyrics level: 2
Then when you start beet import it will move/copy the audio files and arrange them but in addition will move/copy the associated files to the respective locations based on the configs that is: album level files -> album folder artist levelfiles -> artist root folder
zeltak, see https://github.com/sampsyo/beets/issues/111#issuecomment-28128057 on how I manually manage attachments, it's not great.
+1 to attach everything. I just want all the extras which come with the folder
Very interested to see this feature added. Literally the only thing keeping me from using Beets full time for my music org.
Has there been any progress on this?
I've just been writing a plugin to do exactly this. What I've got so far is a plugin that copies any non imported files (album artefacts eg. .log, .cue, etc.) to the destination directory on import. It's a bit rough at the moment, but does the job. I then found this feature request and wondered if anyone has done an implementation of it yet.
I'm happy to work on the plugin and share it (I have a need for it, so I'll be doing it anyway). I develop in Python, so this isn't an issue.
We've made progress on the infrastructure level—flexible attributes have come a long way and we've revamped the data model to make this more feasible. But we're not all the way there yet; contributions are still welcome!
And yes, please do publish your plugin! We'll certainly link to it from the docs at the very least.
Anything I can do to help guys? I think there's a few of us willing attachments on, if there's anything we can do, let us know! :-)
Sami, well done on getting a plugin sorted! :-)
On 13 February 2014 01:29, Adrian Sampson [email protected] wrote:
We've made progress on the infrastructure level--flexible attributes have come a long way and we've revamped the data model to make this more feasible. But we're not all the way there yet; contributions are still welcome!
And yes, please do publish your plugin! We'll certainly link to it from the docs at the very least.
Reply to this email directly or view it on GitHubhttps://github.com/sampsyo/beets/issues/111#issuecomment-34939334 .
Sorry, on a related note. Does anyone have any thoughts or feelings about log files and changing file names via beets...ie. the true spirit of log files is to maintain everything untouched once the log file has been created, so a mismatch between file names and the log file after a beet import kind of defeats the object.
What are people's thoughts on this? I mean, would you still let beets change file names regardless and still include the log file or would you deem it all unnecessary...I guess I'm talking to the audio/FLAC/EAC/pedantic enthusiasts among us.
My approach would be to let beets handle to file names for good structural integrity, and I won't mind about the log file mismatch, but is that the best way to go about this?
On 13 February 2014 12:17, Jonathan Thomas [email protected]:
Anything I can do to help guys? I think there's a few of us willing attachments on, if there's anything we can do, let us know! :-)
Sami, well done on getting a plugin sorted! :-)
On 13 February 2014 01:29, Adrian Sampson [email protected]:
We've made progress on the infrastructure level--flexible attributes have come a long way and we've revamped the data model to make this more feasible. But we're not all the way there yet; contributions are still welcome!
And yes, please do publish your plugin! We'll certainly link to it from the docs at the very least.
Reply to this email directly or view it on GitHubhttps://github.com/sampsyo/beets/issues/111#issuecomment-34939334 .
I agree, let beets change the file names, and keep the log file for reference of the original names.
Yep, from my limited perspective it seems to be the norm to leave the logs alone (due to checksums on EAC logs), regardless of actual file naming
So is it widely accepted that people will alter the file names then?
On 13 February 2014 16:17, Hawke [email protected] wrote:
Yep, from my limited perspective it seems to be the norm to leave the logs alone (due to checksums on EAC logs), regardless of actual file naming
Reply to this email directly or view it on GitHubhttps://github.com/sampsyo/beets/issues/111#issuecomment-34994691 .