-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perfect tool for my workflow but some features are missing.. #115
Comments
Hi, just wanted to say I've been looking into/thinking about both the things in this issue. Regarding modification times, while this is possible, I do have a concern about its affect on backup/file-synchronization. Many tools of this form use the combination of a modification timestamp and the file size to determine if a file has changed. Rewritten media files have a decent chance of remaining the same size, so it's not unlikely that a processed file might be considered to be unchanged by a backup or file synchronization tool, I've been thinking about (and commited to Regarding the recursive option, it should be possible to shell-script this behaviour. I believe I am curious what folder layout you have for files, and how it distinguishes between albums and singles. Also, what platform you are on, as this determines the shells available to you for scripting. |
Hi. Thanks for your changes and for the long comment. It took me a while for replying because I wanted to experiment a little bit changing the rgbpm script for the implementing the recursive update. I initially thought that the performance would not be great but I got it right opusgain is internally multithreaded and the performance is actually quite good (kudos for that). In terms of layout my collection uses the standard setup of one folder per CD and while I agree hypothetically there may be problems in some cases, I don't think that happens for my library as most of my collection is full CDs encoded in opus from the FLAC master. I loved the solution you implemented for the modification times, but when I tried it for real I realized that with this solution the ONLY timestamp that is updated by a single ns is the modification one while the others are updated normally. That result in pretty weird looking times for the files. That may or may not work for I'm trying to achieve, but I need a bit more time for experimenting. As I said my workflow always start with the original FLACs and the opus files are expendable, I don't quite care about backing them up as I can always recreate them from the originals. What I instead to is setting the opus file times exactly like the ones of the FLAC originals since some player will use the file time for sorting the latest additions to my collection. I hope this clarifies my needs a bit more.. |
I've just merged some changes to make it easier to specify album folders on the command line ( |
I think the most relevant change for me is the interpret-paths switch with the folders-are-albums value. This is very convenient when used for tagging a single album. It doesn't seem to work very well for the mass-tagging when re-encoding everything from flac. The other tool I am used to is inflexible in the definition of "album" (a leaf folder with audio files in it) but it would work in both the single album and the mass tagging case. Of course in this case a folder is not an "album", it's just a disc. An album with two subfolders (Disc 1 and Disc 2) will not be tagged correctly. The only way it would work is the case of the album created in a single folder with files marked as disc number-track number-track title.. That's also not the format most people use for storing albums, though. |
Could you elaborate on this? I'm unsure if you're referring to the issues you then mention or something else about the behaviour. Maybe an example of errors, or the command line you are running and the folder/file structure that things are not working for? Given a number of folders and a number of individual files, I assumed this would mostly be able to capture the mass-tagging case, just by using a wildcard path match at the top-level (e.g.
This is the reason why I made |
OK, I think I see the difference. For me a mass tagging operation would always be performed by just passing the root folder of my music collection, let's say ~/Music/opus. It seems to me that in that case everything will be a single album in the folders-are-albums case. Your suggestion is to pass a * argument for each subfolder that actually contains the albums. Correct? |
Let's assume your music is in
The to normalize this, you would go to The result should be that |
Yeah, that was clear to me now, thanks. My issue is that my folder structure depth is not constant. Sometimes I have subfolders like HighRes that contain high-res albums, for instance. What's constant is the view from the leaves. A leaf folder normally contains a disc and sometime the disc is part of an album (one level up). |
Anyway, nothing to worry about, the quirky nature of my folder structure is a problem known to me and I also know how I could fix it (by using tools like beets and renaming/restructring all my collection) but that is a daunting task per se and that I also balk at making for other reasons. |
I have been looking for this tool since I discovered that my opus encoding workflow is subject to the issues you describe in the README and I was ecstatic.
I therefore cloned and compiled it to see if I can switch to using opusgain for maintaining the loudness gain of my audio collection and therefore replace "loudness" that is the tool I'm using now, and the result of my test is this issue.
Opusgain seems to have what I need AND fix my issue but it also is missing a couple of features:
I will of course help out for testing the changes, but unfortunately I'm unable to contribute code (yet) as I'm not familiar with Rust
Thanks
The text was updated successfully, but these errors were encountered: