You are not logged in.

#1 2014-09-11 09:12:22

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Demlo - A dynamic and extensible music library organizer

Demlo organizes your music library automatically and dynamically. It runs a chain of user-defined scripts using variables such as tags and file properties. This way it yields virtually unlimited customization power to the user.

The program core is written in Go while the user scripts are running in a Lua sandbox. Its only major dependency is FFmpeg.

Use case

As an example, consider a music library that is a a perfect definition of chaos:

  • No folder structure.

  • Tags are not homogeneous, some entries are filled, other not, it varies from file to file.

  • Some files have bad audio quality.

  • Audio codecs are not always the same. Some file are CBR/VBR, lossless/lossy, ...

  • mp3's ID3 tags are a nightmare.

  • Covers are sometimes embedded in tags, others are of terrible quality.

Features

A few scripts are already provided and they give a good example of what you can do. You can choose to use them, to rewrite them, or to write a new script from scratch. You can preview changes, and once you are done you call the program over you music library, it will process everything in one single run!
Scripts can be chained: this feature makes Demlo extremely flexible and powerful!

  • Move all files according to a unique, yet dynamic folder hierarchy. For
    instance, setting
    output.filename = table.concat {library, '/', o.artist, '/',
                     not empty (o.album) and (empty (o.date) and o.album .. '/' or o.date .. ' - ' .. o.album .. '/') or '',
                     empty (track_padded) and '' or track_padded .. ' - ',
                     o.title}

    will move "john doe - 1. intro.ogg" to

    • "/home/$USER/music/John Doe/2013 - Great Album/01 - Intro.ogg" if there is an album and a date,

    • "/home/$USER/music/John Doe/Great Album/01 - Intro.ogg" if there is an album and no date,

    • "/home/$USER/music/John Doe/01 - Intro.ogg" if there is no album.

  • Case checking: a powerful script that will turn everything to title case. It supports special cases such as Roman numerals, McDonald, etc. It also supports a list of exceptions (e.g. AC-DC, DJ, feat., etc.).

  • Encoding: you can conditionally re-encode you files, so you can choose to only re-encode files with some particular encoding settings. You can set the desired bitrate, etc.

  • Covers: automatically remove embedded covers, remove duplicates, remove files beyond/below a quality threshold, etc.

  • Different kinds of music: classical, OST, and band songs have usually different kinds of tags and folder structures. You can manage different audio libraries easily by setting the corresponding "library" variables.

  • Edit tags of a file set with your favorite text editor.

  • Support for cue sheets. (Both external and embedded.)

  • Demlo can be interfaced with any other program, both ways. (X calls Demlo or Demlo calls X.)

  • MusicBrainz support for online tagging and cover fetching.

Links

Last edited by Ambrevar (2017-04-05 11:04:38)

Offline

#2 2014-09-11 12:28:22

sekret
Member
Registered: 2013-07-22
Posts: 283

Re: Demlo - A dynamic and extensible music library organizer

Very interesting!! I don't need it, because my library is beautifully structured, but such tools are VERY helpful.

Offline

#3 2014-09-11 12:43:48

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Demlo - A dynamic and extensible music library organizer

 Great addition. Not wanting to diminish your contribution, have you looked into MusicBrainz Picard?

Offline

#4 2014-09-11 16:08:15

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

sekret wrote:

Very interesting!! I don't need it, because my library is beautifully structured, but such tools are VERY helpful.

You don't need it until you start using it! big_smile
I used to be a sorting psycho and thus had a perfectly sorted music library. (At least that was what I thought.) But that was such a hassle to maintain in the long run! Combining different tools and scripts to help me out was not enough, I lacked something *very* solid and dynamic. Hence the development of this tool.

As an experiment you could try the following on your library: write a script that matches your sorting rules (simply adapt from the default script, that is just a matter of minutes even if you do not know Lua), and preview the result over your library. You should be able to spot inconsistencies. Or not, if you are really a sorting psycho! smile

Last edited by Ambrevar (2014-09-11 16:58:02)

Offline

#5 2014-09-11 16:32:22

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

emeres wrote:

 Great addition. Not wanting to diminish your contribution, have you looked into MusicBrainz Picard?

Indeed. I tried all of them: Easytag, kid3, Picard, Amarok... MediaMonkey turned out to be one of my favorite with its titlecase script (albeit very limited), but still. All these programs take the same approach, they split the process in 3 individual tasks: Internet tagging, file renaming, tagging from file names.
And they all lack tagging from tags.

What Demlo provides here is fundamentally more powerful: the tasks 'file renaming', tagging from file names' and 'tagging from tags' are centralized into a Turing-complete environment, the 'script'. Which brings the killer-features forward:

  • The competitors use some regular pseudo-languages for file paths and so on. Being Turing-complete brings it one level further in terms of customization.

  • The 3 tasks are no longer separated so you can combine features. For instance you can set a condition on both tags and file names.

  • No need to run the three tasks manually one after the other, you can process everything at once.

This is the major feature. Along with some very welcome additions I've already mentioned, such as a great working titlecase script, transcoding, cover support, cue sheet splitter, etc.

Offline

#6 2014-09-11 17:05:14

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Demlo - A dynamic and extensible music library organizer

 My old music library usually needs cleaning up, so I always prefer taking tags from MusicBrainz database, even if I erip my own physical music and it is not present in the database, then I upload it and take it from the server. I consider Picard powerful enough, the only thing that I am missing is creating symlinks for compilations, redundant entries, combined/spliced artists and tracks. Should anyone know anything about that please inform me.
 Can Demlo fingerprint music? Could Demlo parse the metadata from the MusicBrainz database? I will have a look at it later.

Offline

#7 2014-09-11 17:46:23

sekret
Member
Registered: 2013-07-22
Posts: 283

Re: Demlo - A dynamic and extensible music library organizer

Ambrevar wrote:

You should be able to spot inconsistencies. Or not, if you are really a sorting psycho! smile

Challenge accepted wink

Offline

#8 2014-09-11 21:53:13

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

@emeres: You just brought up some interesting improvement ideas.

emeres wrote:

Could Demlo parse the metadata from the MusicBrainz database?

Support for syncing with online services such as MusicBrainz and freedb are still to be implemented. I might do it anytime soon if I find an obvious solution. Any help is very much appreciated. smile

emeres wrote:

the only thing that I am missing is creating symlinks for compilations, redundant entries, combined/spliced artists and tracks. Should anyone know anything about that please inform me. Can Demlo fingerprint music?

Can you elaborate a little on the symlink problem? Maybe with an excerpt from your library tree. If I got it correctly, in an <artist>/<album>/<track> hierarchy, we can have duplicate files like this:

  • John Doe/Ballads/Lovely Song

  • Various Artists/Movie with nice musics/John Doe - Lovely Song

It usually happens with compilations and OSTs.

To prevent this, we could use symlinks. Or hard links. But is it really a good idea? As soon as you want to split your library (e.g. transfer one album on another machine), you need to follow symlinks, otherwise you will end up with missing files. Hard links do not hava this problem, but do not work across file systems.

Besides, if we opt for symlinks, which file should be the reference file, which one should be a symlink? One way to decide this would be to check for the oldest date in the metadata. But I fear that might be a tad clunky. Other than that, I don't think this can be decided other than randomly or manually. Again, hard links do not have this problem.

To sum up, I would opt for hard links. What do you think?


To lookup duplicate musics we need to fingerprint the audio files and to index them all. We keep the file with highest quality below a user-defined threshold. If the library is large, it will be tremendously time and resource demanding. Still doable.

This looks like an independent project to me. And Demlo could call it upon renaming / copying.

Offline

#9 2014-09-11 23:23:09

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Demlo - A dynamic and extensible music library organizer

Ambrevar wrote:

This looks like an independent project to me. And Demlo could call it upon renaming / copying.

A fuse filesystem like tagfs, dantalian, tagsistant or maybe even id3fsd might be the right idea here.


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#10 2014-09-12 02:01:38

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Demlo - A dynamic and extensible music library organizer

 My music library structure looks like this for now*:

/Music/Music Library
├── [Compilation]
│   ├── #
│   ├── A
[...]
│   ├── E
│   │   ├── Entheos Audio Archive 1.0 - [2007][FLAC]
[...]
│   ├── Z
│   └── 攻
├── #
│   ├── ([ ])
├── A
├── B
├── C
[...]
├── L
│   ├── Lauge & Baba Gnohm
│   │   └── 2009 - Monolith [Extended Play][FLAC]
[...]
└── Z

 For further reference take a look at this file naming script for Picard. Still work in progress though, based on multiple sources.

 So what I would like to have is [sym]links for each Artist from a Compilation/joint work, unless specified otherwise or maybe better when specified explicitly, to their own Artist folder. One example would be to symlink Lauge and Baba Gnohm to their common work. But this is for the whole album/release. Yes, it could be considered a VA case.

├── B
│   └── Baba Gnohm
│       └── 2009 - Monolith [Extended Play][FLAC] # Link
├── L
│   ├── Lauge
│   │   └── 2009 - Monolith [Extended Play][FLAC] # Link
│   └─── Lauge & Baba Gnohm
│       └── 2009 - Monolith [Extended Play][FLAC] # Original

Single tracks from compilations should be linked in this manner:

/Music/Music Library/P/Pharoelidae/[Compilation]/Entheos Audio Archive 1.0 - [2007][FLAC]
└── 01. Pharoelidae - Entheognosis.flac # Link

/Music/Music Library/[Compilation]/E/Entheos Audio Archive 1.0 - [2007][FLAC]
├── 01. Pharoelidae - Entheognosis.flac # Original
[...]

 This would result in many entries from larger compilations. Quality aspects do not really concern me, since I tend to use lossless sources anyway. The problem is how to maintain those links and handle newcomers that would overwrite a single or several tracks, probably through manual intervention. Not to mention that, this would eventually end up in a copy of MusicBrainz database/library, since the references could be expanded to further relations, which a sorting psycho will probably end up with. Both of the above should be doable with Picard, especially the compilation-artist linking seems easy, but it probably would end up in writing a plugin for symlinking.

 The pain of ones own carelessness, read stupidity, that resulted in deleting an album with some great tracks, whose name was of course forgotten and meant weeks of searching, makes me somewhat cautious towards hard links, but other than that, I am all for it. I do not see problems with symlinks when copying however.

There are some unique cases in my music library/sorting stash if I recall correctly, but it would take a great amount of time to find them now. I just have too much music to filter out and 960 entries in my Ektoplazm feed, which I have to go through eventually, probably when I am already dead at this pace.

@progandy Interesting suggestions, but in my case for compatibility reasons ntfs in that structure will remain for now. I will test those however in the near future.

Side note: *One of the main reasons I use MB Picard is the ease with which I can rebuild the whole library, especially after first tagging. There are some limitations to it as well to the whole approach of structuring the music library, where tagfs and similar seem very appropriate.

Edit: Added clarification.

Last edited by emeres (2014-09-12 02:05:44)

Offline

#11 2014-09-12 02:13:43

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Demlo - A dynamic and extensible music library organizer

@progandy Interesting suggestions, but in my case for compatibility reasons ntfs will remain for now. I will test those however in the near future.

dokan (or the newer fork dokanx) can provide a basis for your to write the same tagged filesystem for windows.


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#12 2014-09-12 03:11:06

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Demlo - A dynamic and extensible music library organizer

 I would not touch Windows with a stick. Writing anything for closed source systems is from my point of view a waste of {time, health, life, and resources}. Thanks for the suggestions though. Like I already wrote, I will take a look at tagfs, which looks very promising so far, thank you for bringing it to my attention, and the rest. Maybe I can run them in parallel and eventually switch, but the ntfs and file structure of the music library needs to stay in place, at least for now.

Offline

#13 2014-09-12 10:42:31

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

@emeres: As far as I understand, you would like to have a filesystem "view" of your library that could be browsable by tags (at least by artists). Thinking about it, a similar feature is provided by most library managers where you can choose filters and tree structure and so on. It remains virtual though, it does not touch the filesystem. Is it really necessary to you to have that sort of view directly on your filesystem? The problem of the filesystem view seems very complex to me.

Furthermore, would you consider this to be an automated task or a manual one? Using your example, how can a program know that Lauge & Baba Gnohm is both Lauge and Baba Gnohm if no tags says so?

Hard links do not work for folders.
Symlinks cause problems with most file browsers that do not follow them during copying.

One of the main reasons I use MB Picard is the ease with which I can rebuild the whole library, especially after first tagging. There are some limitations to it as well to the whole approach of structuring the music library

Can you elaborate on this? What are the limitations of Picard beyond symlinking? It could be interesting to know what feature you would like.

Offline

#14 2014-09-12 12:29:12

emeres
Member
Registered: 2013-10-08
Posts: 1,570

Re: Demlo - A dynamic and extensible music library organizer

 I hoped the structure I presented was clear enough. No, all/majority of tags would be a little too much, but genre, different release types, file types and some other basic distinctions, yes and tagsfs will probably help with that. There are special folders like [Compilation], [High Voltage SID Collection] and probably others in the future, maybe with help of tagsfs. Compilations and Artists are prepended by the leading letter of 'sorted artists/albums' level. Then albums/artists are sorted/presented in the manner visible in the Picard script:

$if($eq(%compilation%,1),
%COMPILATION%///%FIRSTLETTER%///$if2(%ALBUM%,%NONALBUMTRACKS%,[Other]) - $if(%DATE%,[%DATE%],),
%FIRSTLETTER%///$trim($if2(%ALBUMARTIST%,%ARTIST%),.)///$if(%DATE%,%DATE% - ,)$if2(%ALBUM%,%NONALBUMTRACKS%,[Other]) )
$if(%RELEASETYPE%,[%RELEASETYPE%],)%BARCODE%$if(%INCOMPLETE%,[%INCOMPLETE%],)[%EXT%]///
$if(%DISCNUMBER%,%DISCNUMBER%-,)%TRACKNUMBER%. %ARTIST% - %TITLE%

 Picard has preview examples, so copying the whole script into file naming script under options should make this definitely clear.

Ambrevar wrote:

Thinking about it, a similar feature is provided by most library managers where you can choose filters and tree structure and so on. It remains virtual though, it does not touch the filesystem. Is it really necessary to you to have that sort of view directly on your filesystem? The problem of the filesystem view seems very complex to me.

Not all devices provide that capability. It is more pleasant to work with that approach than previous structures I used, remember that I can restructure the whole library at any time and probably copy the local one elsewhere using the new structure, but I have not looked into that yet.
 We probably have very different experiences, I see this as very comfortable and convenient. Before that I had been using folders for different file types in the main directory, but it ended up with so many entries for FLAC and MP3, that parsing that directories in a player or any maintenance using a file browser/terminal was too troublesome/slow. So I reduced the number of files, by using the alphabet and additional characters as sorting mechanism. And since that was one step away from separating compilations from albums/single releases, I did that also. Now I can access the whole library very quickly, even when one or two additional characters need to be typed.

Ambrevar wrote:

Furthermore, would you consider this to be an automated task or a manual one? Using your example, how can a program know that Lauge & Baba Gnohm is both Lauge and Baba Gnohm if no tags says so?

 Both, I want as always full control. MusicBrainz [database] relations.

Ambrevar wrote:

Hard links do not work for folders.
Symlinks cause problems with most file browsers that do not follow them during copying.

 I do not recall writing they should link folders, the directory structure would have to be [re]build and then files [hard/sym]linked, which might pose a maintenance issue, although deleting links and empty directories not really, but "leftovers" like covers could block cleaning. *The only file browser* I would recommend is Proto from a very friendly Polish programmer named Mieszko Lassota, but it is, or at least was last time I checked, Windows only and slowly further developed, although still kills every mc, mucommander and ranger on sight, that is how I remember it. SpaceFM is bearable, but I still only use rsync to copy files and see no point using anything else.

Ambrevar wrote:

Can you elaborate on this? What are the limitations of Picard beyond symlinking? It could be interesting to know what feature you would like.

 The recursive/linking aspect it the main point here. I hope this is not too big of a disappointment. Having too long names has also been a problem in few cases, classical music if I recall correctly, but those are limitations of the file system, however even that could be overcome with Picard, but the code would not be as easily readable as it is now. The question would be what should be abbreviated/priorities, what to do when after abbreviation the directory/file names are still too long and so on. I had to do it by hand these few times. Picard does not handle covers/images well in my experience, but I used something else for that, puddletag I think. I would have to continue to organize the library to remember.
 Furthermore, not all media players/organizers do have the capability to get exactly this structure with formatting, leading letters and distinction between compilations and albums being two examples. Browsing this robust file structure with ncmpcpp is very efficient, I almost never use the library view. As long as a media player has the browsing capability, I have the same view/behavior. And other hardware also works without issues. Yes, it basically comes down to having the file system do, what media players should, however with a few exceptions I had only positive results for more than almost two years now. Do you now see benefits of having that file structure?
 Again I will take a look at your tool, when I find some time and what progandy suggested also of course. How do you save your music on the file system?

Edit: Style. Clarification.

Last edited by emeres (2014-09-12 13:02:34)

Offline

#15 2014-10-03 08:34:29

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

(I was offline for a while, sorry for the late reply.)

@emeres: This filesystem sorting is very interesting. There is definitely some tool to develop to create a tag-based virtual filesystem. This is way beyond the scope of Demlo however. But again, Demlo can certainly help in that regard.

The music is saved through FFmpeg only, which means it is never moved/renamed.
This "feature" was meant as a security measure against unexpected destruction of
source files. But I concede that if the file is not modified whatsoever, an
interesting feature would be to able to rename them. I will do experiment very
soon.

@sekret: Did you dare attempting the challenge? smile
By the way I have updated the man page and the AUR package to include a sample configuration file.

Offline

#16 2014-10-12 18:33:20

axugen
Member
Registered: 2014-04-04
Posts: 2

Re: Demlo - A dynamic and extensible music library organizer

Have you ever heard of beets? It does a similiar job, im interested to see how Demlo fares against it.
http://beets.radbox.org/

Offline

#17 2014-10-13 08:25:23

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

Thank you for the hint, I never heard of this app before. Looks very inspiring indeed!

I will have a look later and write a comparative review. At first glance I would say they definitely belong to the same category of tools while taking a very different approach.

Sounds like a nice competitor! smile

Offline

#18 2014-10-13 09:07:19

parchd
Member
Registered: 2014-03-08
Posts: 421

Re: Demlo - A dynamic and extensible music library organizer

I tried using beets a few months ago, but my music collection is so large and was in such a mess to start off with that I eventually killed the process it was running and had my collection in a bigger mess than before (or, probably more correctly, in less of a mess but with me no longer knowing where things lived). I would like to organise my collection, so I'll be trying this at some point.

Offline

#19 2014-10-13 10:57:05

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

Demlo gives you a lot of control over what is changed (audio stream, tags, cover, filename). By default, source files are not modified, and you can clearly separate the input and output trees to avoid any confusion.

Performance-wise, Demlo performs great on a few hundreds of files at least. (Lua is blazingly fast, plus the process can be threaded.) The process is extremely fast if you only rename files, moderately fast if you change tags but not the audio stream, but quite slow of you convert the audio stream. Not much I can do about that, FFmpeg is the bottleneck here.

I never tried with a gigantic collection, but I believe the program scales well. Would be interesting to get some practical feedback.
My only concern is that Demlo performs some memoization to speed up redundant queries. Memoized data is never cleaned up for now. This might yield a memory hog when run on thousand of files. I am not sure how relevant this is.

I am about to release a new version with load of new features: file renaming, MusicBrainz support, cover download, chained scripts, and more. Stay tuned smile

Last edited by Ambrevar (2014-10-13 10:58:05)

Offline

#20 2014-10-14 14:32:47

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

I just released version 1.2! Main highlights:

* File renaming.
* Tagging from MusicBrainz.
* Fetching covers from MusicBrainz / Coverarchive.
* Chainable scripts.

Only the 'output' table is used in default scripts. The 'input' table is read-only. This enforces consistency and allows chaining scripts.

I came up with the idea of chaining scripts recently as I felt running only one script at a time was not flexible enough. Now you can control precisely what you want to change: tags, covers, codec, filename, etc.

It makes it possible to run Demlo for specific actions only instead of starting the whole machinery every time. A few examples:

* You can rename every file in your library to fit a new hierarchy. Since the content is not modified (codec, tag, embedded cover), the process is extremely fast.
* You can automatically fetch all covers for your library.
* You can apply the case checker and then rename files if necessary.

For MusicBrainz support I use fingerprinting with Chromaprint. This is quite slow (fingerprinting + at least 2 network requests). However I have tried to be smart and to optimize per-album processing: thanks to a not-so-obvious heuristic to identify albums, I perform the fingerprinting + network operations only once per album.

Feedback is very much appreciated! smile

Last edited by Ambrevar (2014-10-14 17:08:20)

Offline

#21 2014-10-14 17:32:09

Runiq
Member
From: Germany
Registered: 2008-10-29
Posts: 1,053

Re: Demlo - A dynamic and extensible music library organizer

Ambrevar wrote:

* Tagging from MusicBrainz.

Now we're talkin'. smile I'll be sure to try this out, seeing how I'm a die-hard beets user as well.

Offline

#22 2014-10-14 22:11:19

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

I've been playing with beets a little. It is a huge program with a lot of possibilities, so my current knowledge might not be good enough to rate it properly. Nonetheless I'll try to write a comparative review with Demlo as precise as I can tell for now.

* Approach: Beets is library oriented (it maintains its own database) while Demlo is more of a batch tool.

* Extensibility: Demlo strives at being as generic as possible while leaving full control to the user through Lua scripts. Beets takes a less do-it-yourself approach and provides many plugins by default, one per every single feature. There is a huge incentive to develop one plugin per functionality, which is far less the case for Demlo. For instance, beets ships with the Scrub, Zero and FtInTitle plugins, all for tagging. Demlo has only one 'tag' script to do it all, yet still easily customizable through the prescript and postscript from command-line.

* Command-line: Demlo is a batch tool, therefore there is no interaction. Beets is much more interactive, even though it can be made quite silent as well.

* Implementation: Beets is written in Python 2.7, Demlo in Lua. Demlo has much lighter dependencies, and the program itself is ~10 times lighter.

* Extra attributes: Beets can fetch lyrics, acoustic attributes, bpm, and much more. None of this is available in Demlo, nor is it easy to add since it has no plugin support.

* Extra features: Beet can play music through a web server, it can list and search your library, and more. None of this is possible with Demlo. This is a design choice, Demlo strives at being an audio file batch processor and nothing more (Unix philosophy).

* Interface: Demlo is interfacable with JSON input/output. Not sure about beets: it seems like it is not interfacable from command-line, but it has an interfacable library according to this page: http://beets.readthedocs.org/en/v1.3.8/dev/api.html.

* Library database: Demlo, by design, has no internal database to keep track of your files. This could potentially allow Beets to work conditionally on the content of the library (not sure if it is possible). Demlo processes one file after the other, there is no way to work conditionally on a music library.

* Internet support: Beets was thought with Internet tagging in mind. It supports MusicBrainz and Discogs + other services. Demlo only supports MusicBrainz. The default heuristic in Demlo yields better results to me, but Beets' heuristic is configurable. (Demlo's is not.)

* Duplicates: Beets can detect duplicate music files: http://beets.readthedocs.org/en/v1.3.8/ … cates.html. Since Demlo does not maintain any kind of database, there is not much it can do in that regard.

* Customization: most of the configuration / customization happens through expressions (see file naming) which can be somewhat limited. Even with the inline plugin, there is usually little communication between different commands / plugins, which makes it difficult to use the result of one command/plugin in another. Everything in Demlo is in Lua and lives in the same environment. As such it is possible to combine features in any desired way.

For me this last criterion is the killer feature of Demlo compared to Beets. Overall, I must say Beets seems like a very powerful piece of software. I like the duplicate detection and all the extra online features.

Last edited by Ambrevar (2014-11-05 10:32:18)

Offline

#23 2014-10-15 09:11:29

KingYes
Member
From: Israel
Registered: 2011-05-08
Posts: 120
Website

Re: Demlo - A dynamic and extensible music library organizer

Nice work !
Is have a GUI version atm?


Web Developer.

Offline

#24 2014-10-15 09:19:19

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

Thanks!
Nope, no GUI at the moment, even though I am thinking about it.

If you are thinking of interactive tag editing, it is still possible thanks to the 'index' feature: you can output the tags to a JSON file, edit it with your favorite editor, then use this modified file as initial values for the 'output' table.

Offline

#25 2014-10-18 10:07:06

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: Demlo - A dynamic and extensible music library organizer

I have recently been working on classical music (classical in the broad sense) as it is a little trickier to organize than regular band music. There are usually  several releases for a single piece, a lot of them are actually compilations. There is a difference between the composer and the performer (who can be the orchestra, the conductor, ...), so the question who are the artist and the album artist is left as a raveled mystery to the world.

I modified the default script 'tag' and 'filename' to handle these cases with more grace. For instance the filename will be

    album_artist/album (performer, year)/track. artist - title

'artist' is the composer.

'album_artist' is 'artist' if not a compilation, or the group in charge of the compilation otherwise.

'artist - ' does not appear in the filename if 'artist' == 'album_artist'.

'performer' is the performer of the album, who may be the conductor,

The reason we add the performer and the date in the filename is to help distinguishing albums (a performer can perform the piece several times). Furthermore, we are not so much interested in sorting them by date (as opposed to band albums), so we specify it after the album name.

For instance this kind of filenaming can yield

    Dvořák/Symphony No. 9 "From the New World"
    Dvořák/Symphony No. 9 "From the New World" (Karajan, 1959)
    Dvořák/Symphony No. 9 "From the New World" (Karajan, 1985)
    Dvořák/Symphony No. 9 "From the New World" (Vienna Philharmonic Orchestra)

One has unspecified performer, one has a performer but no date, and the others have both.

This is now the default behaviour in the recently pushed version 1.3. Of course one is free to choose their own script for tagging and filenaming.

Offline

Board footer

Powered by FluxBB