Skip to content
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

Option to skip calculation if tags are present #7

Open
phw opened this issue Sep 5, 2019 · 11 comments
Open

Option to skip calculation if tags are present #7

phw opened this issue Sep 5, 2019 · 11 comments
Labels
enhancement New feature or request usage Usage questions and examples wontfix This will not be worked on

Comments

@phw
Copy link

phw commented Sep 5, 2019

It would be great to have a command line switch which would disable recalculation of the replaygain if the tags are already present. This would allow to easily run loudgain on a large folder but only process those files which do not have ReplayGain calculated.

@Moonbase59
Copy link
Owner

Yeah, I somehow agree … but …

  • it’s tremendously difficult to check if a max. of 7 tags are already there and correct and agree with the other commandline options. All the extra logic is probably not worth the effort.
  • loudgain will currently analyze all files anyway, to check for errors and arrive at correct album values. This step is done before actually writing any tags, so there wouldn’t be any speed advantage.

So in order to always have the best and most exact results, I’ll probably not intruduce this feature—it seems a little unreliable to me.

But let’s leave this open for discussion for now, shall we?

@Moonbase59 Moonbase59 changed the title Option to skip calculation of tags are present Option to skip calculation if tags are present Sep 5, 2019
@phw
Copy link
Author

phw commented Sep 5, 2019

Fair enough, I think this could also be handled by a wrapper script that checks for tags and invokes loudgain if necessary.

loudgain will currently analyze all files _anyway_, to check for errors and arrive at correct album values. This step is done _before_ actually writing any tags, so there wouldn’t be any speed advantage.

The idea would have definitely been not to analyze the file. But the point with album values is good. As I understand this would mean the check for present tags would need to check all tags for all analyzed files, and if one file is missing tags all files need to be analyzed anyway to get proper album values. Same would be true if the album values differ in the analyzed files. I tend to agree that this complexity does not really warrant this feature.

@Moonbase59
Copy link
Owner

Yep. And you wouldn’t believe what users come up with … mixing MP3, FLAC and Opus together in one folder "to make my album complete" (an actual case). Was hard enough checking for such crazy situations … ;-)

The checking logic would be perverse, and we still wouldn’t know if the existing values were ReplayGain 1, ReplayGain 2, if the peak values were sample peak, RMS peak, or true peak … and so on and so forth. So better do it once again—and correctly. After all, this would normally only been done once.

@Moonbase59 Moonbase59 added enhancement New feature or request wontfix This will not be worked on labels Sep 5, 2019
@flittermice
Copy link

I just came across to ask for the very same feature (like I was used from mp3gain). But I can understand why you refrain from implementing "half things" like that (on the other side... people who mix different formats will either not care of REPLAYGAIN or will exactly know what they do).

I will write some wrapper script in the manner of putting some ".replaygain-tagged" file in the corresponding folder and skip on that base. Thanks for the excellent work so far, this was really needed!

@Moonbase59
Copy link
Owner

Maybe you can adapt the rgbpm script to do that. Let me know.

@flittermice
Copy link

Sure, here's my already adapted script. But beware - I crippled it for fitting just for my personal needs for the moment.
Musik_loudgain-recursive.sh.txt

@Moonbase59
Copy link
Owner

Moonbase59 commented Sep 27, 2019

Thanks for sharing! A nice example for others how to modify rgbpm to their personal needs.

Note: You shouldn’t modify the original (installed) version—it will be copied over by the next upgrade of loudgain. Instead, make a copy and put that in a feasible place (like /usr/local/bin or your personal ~/bin folder.

N.B.: Are you sure you want ID3v2.4 only for MP3 but not for MP2, WAV and AIFF?

@phw
Copy link
Author

phw commented Sep 27, 2019

Maybe this or a similar script could be provided as an example. Either include it directly in the repository or link to it in the README. Would this make sense? From my point of view something like this would resolve the issue here.

@Moonbase59
Copy link
Owner

Moonbase59 commented Sep 27, 2019

Well, I’m not too much a fan of flags, which might get outdated if something else writes to the files. But yes, I agree, we could put a link in README, as "user example" or such.

For inspecting folders by a human, it might actually even be nice to have a visual indication that files in the folder have been replaygained, or album-gained. Depends on the use case, as always.
Anyway, I build on the ideas of others, and I love people building on my ideas. :-)

@Moonbase59 Moonbase59 added the usage Usage questions and examples label Sep 27, 2019
@flittermice
Copy link

Thanks for the postive reaction to my NOOB script :-)
As said, this was intended only for my personal use. There are many things that have to be improved, e.g.:

  • Error handling: What to do when the something went wrong after invoking "loudgain"? Presently, the $RG_TAGGED file will be written in any case (I personally double check using Mp3tag).
  • I removed a few things like BPM calculating which doesn't work for me or my type of music anyway.
  • make it English again
  • etc.

@Moonbase59: Note: Surely, I did this on a copy that I copied from the source tree.
@phw: Thanks for the hint, but I don't care for formats besides MP3 and FLAC.

@Moonbase59
Copy link
Owner

Thanks for your input. I added a section Mass tagging to the README. Please comment if I’ve got anything wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request usage Usage questions and examples wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants