thomasvs
feedback
My reactions after scripting morituri for 5 cdrom drives (1 Lite-on LTD166 and 4 Asus blah blah blah), and ripping ~50 audio CDs... I've been using EAC on Windows and iTunes on Mac and - long ago - cdparanoia.
I'm ripping classical CDs almost exclusively. Some Celtic music, some jazz.
I don't use the templates for track names or disc names. The logs are disc.log etc, the tracks are [1-N].flac etc, and the disc directory names are generated by mktemp. I intend to populate a database with album / track / performer / composer metadata, rather than use the filesystem to track metadata. I'll use extended attributes to associate metadata with each track.
Partly this is because conventional templating doesn't easily accommodate the variations in classical album metadata.
-
Mostly very happy with morituri. It does about 90% of what I need from a ripper, it is way easier to use than EAC, I can rip multiple CDs in parallel, it is scriptable, and it is *nix. W00t!
-
Others have commented about metadata retrieval. I have similar problems.
First, I'm getting about a 50% hit rate, which is astonishingly low. I bought most of my albums between 1970 and 2000 .. and most of the albums were reasonably popular (for classical music) back in the day. For instance, the reissue of Charles Rosen's recordings of Beethoven's Late Piano Sonatas isn't exactly an obscure recording.
It would be helpful if morituri were to log breadcrumbs when it finds the metadata at another database; in this case morituri (or whatever tool morituri calls for reading databases) found the metadata at FreeDB... why not use that metadata? or at least pass it along to the log... But no, log says "Album: Unknown Artist - Unknown Title." No indication except on console output that morituri even looked at FreeDB.
Second, it's quite amusing to see Prokofiev's name in Cyrillic, but (sadly) Cyrillic is not much use to me.
I'm not bothered (much) by either of these shortfalls, because morituri logs enough information (CDDB disc id, MusicBrainz disc id and URL) that I should be able to come back later with a different tool and reconstruct usable metadata information; I filter console output to recover alternate DB lookups.
- As said, I use mktemp to generate album directories. Imagine my surprise when I finally realized (after about 20 albums) that morituri really seriously wants to create the directories itself, and often (but not always - race condition?) barfs its cookies when it finds the directory already made for it. Usually I get two errors - that the directory exists, and that the disc has already been ripped (I forget the exact wording.)
I can guess why morituri checks, but it took me a while to figure out what was going on ... the "has already been ripped" error message is incorrect; and even if it were correct, so what? why not allow the user to override the error with an option (e.g. to overwrite existing files)?
I've worked around this with the obvious (ugly) hack of using mktemp to create the directory, then rmdir'ing the directory, then invoking rip; no doubt less ugly work-arounds exist, but this works..
Still, better not to have to create ugly work-arounds.
- Documentation is a bit on the spartan side.
I don't understand the point of the language about relative and absolute pathnames ... I experimented with both, and am still puzzled. I think I get the point about the working directory and the output directory (perhaps using both is the better way to deal with morituri's insistence on creating its own directories - which, come to think of it, isn't mentioned in the dox - but when I tried setting -W and -O with the same destination, rip wasn't happy. Point being that I didn't initially understand the use of -W and -O from the description in the dox.)
The use of LOCALE isn't mentioned (well, perhaps it is, and I missed the mention.) Seems as if LOCALE might be relevant to the choice of metadata matches, but I'm just guessing.
- morituri can't rip a multi-track CD to a single output track, as best I can tell.
This is absolutely essential for many classical music albums, e.g. some / most? of Bach's keyboard music. Operas ...
Again, not a deal-breaker, I'll find another tool to use... but still ...
- Consider this "constructive feedback", not criticism. As I said, morituri does most of what I want. Where morituri's shortfalls get in the way, I have been able to get around them, or see how I should be able to get around them.
"One of the problems with making a system foolproof is that fools are so unreasonably clever."
Nice job.
Jim Snyder
Hi,
thanks for the feedback.
Taking it point by point.
- first. I personally think that FreeDB's database is pretty bad. There are no style guides, and people just put in whatever they want. The same album ends up in all genres if popular enough. People put The Rolling Stones as Rolling Stones, The or Rolling Stones or Rolling Stones (The). Spelling mistakes abound. It's really hard to fix any data in there. And if you add a disc to it, it doesn't appear immediately in the database anyway, so even if you feel motivated to add it you can't use that info for morituri straight away.
Musicbrainz is way better, and as such I saw morituri as an opportunity to help out musicbrainz as well. Whenever morituri doesn't find a CD in musicbrainz, it gives you a link to add it, and musicbrainz lets you import and correct the data from freedb. So, while it's not clearly stated as such, the idea is that you add a missing disc to musicbrainz based on the freedb info.
In addition, freedb is also missing info that would be used otherwise, so I'm not very motivated to add freedb support as well - at least not until all of the regular metadata issues are resolved.
The generated log file is more about the files produced and the end result, and not about things that have happened along the way. It was modelled on EAC's log, IIRC that doesn't mention freedb either (though it only supports freedb).
Also, morituri can take one of these Unknown Artist - Unknown Album directories and retag/rewrite them based on musicbrainz data after a rip too.
-
Second - I've had this happen on one CD myself - the jonny greenwood soundtrack I think - but I'd have to revisit it in more detail. If you have a specific musicbrainz disc id you want me to look at and what you would expect, that would help - basically I need (or need to make) a unit test case and keep it fixed.
-
Yes, that check only checks if the dir is present iirc. I added that after my rips silently overwrote previous rips of different singles or eps with the same name. A force option would be ok, but I wouldn't want it as the default. Patch accepted. I'm not sure I entirely understand your use case here - why can't you just let it write its directory under your temp directory instead of right in it, and then move the results up?
-
working directory is where morituri will 'run' from. This is a section of the path that thus can be 'hidden' from log files if you use relative directory for the output directory. I don't like having full paths in my logs. Don't know if that makes it clearer?
LOCALE indeed isn't mentioned. Basically, I have no interest in supporting non-utf8 LOCALES because I never use them and I don't think it makes sense anymore to use them. I believe you were using a C locale ? What was your reason for that ?
- correct. It's entirely possible, it just hasn't been a priority for me. Why is it absolutely essential? Isn't it up to the player to hide the implementation detail that the different parts are in different files?
In any case, it would be totally doable, it would just need a lot of code to generate the proper .cue file.
- I appreciate feedback! It helps me go forward in certain directions. Especially for use for classical music, as I don't listen to it it's really hard for me to think through those use cases. So I'm interested in getting recommendations for those cases.
I always find tagging classical music challenging. I basically gave up on doing so though the ripping process. An excellent tagger for classical music is available here:
http://qoobar.sourceforge.net/en/index.htm
