Bug 248668 - [NEW PORT] audio/loudgain: ReplayGain 2.0 loudness normalizer
Summary: [NEW PORT] audio/loudgain: ReplayGain 2.0 loudness normalizer
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL: https://github.com/Moonbase59/loudgain
Keywords: feature, needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2020-08-15 09:46 UTC by Cluboq
Modified: 2020-08-16 18:40 UTC (History)
2 users (show)

See Also:
clubok: maintainer-feedback? (clubok)


Attachments
loudgain port skeleton (2.41 KB, application/x-shellscript)
2020-08-15 09:46 UTC, Cluboq
no flags Details
loudgain port skeleton with gunk removal moved to post-extract target (2.41 KB, application/x-shellscript)
2020-08-15 09:55 UTC, Cluboq
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cluboq 2020-08-15 09:46:05 UTC
Created attachment 217228 [details]
loudgain port skeleton

loudgain is a versatile ReplayGain 2.0 loudness normalizer, based on the
EBU R128/ITU BS.1770 standard (-18 LUFS) and supports
FLAC/Ogg/MP2/MP3/MP4/M4A/ALAC/Opus/ASF/WMA/WAV/WavPack/AIFF/APE audio files.
It uses the well-known mp3gain commandline syntax but will never modify the
actual audio data.

WWW: https://github.com/Moonbase59/loudgain

Built and run successfully on FreeBSD 11.4-RELEASE-p2 amd64, all dependencies built and installed from source by the Ports system, all being latest versions.

The latest portlint's check result: "looks fine".

If accepted, this is going to be AFAIK the only non-destructive audio normalizer in the Ports tree that can do Opus files.

Note: the upstream GitHub repo currently includes static Linux binary and a .deb package of loudgain in the release tag, which increase the tarball to 26 Mbytes (otherwise the distfile size would have been a lot smaller). Those files are deleted by the post-patch target. Upstream promises to deal with the issue eventually: https://github.com/Moonbase59/loudgain/issues/12
Hope that won't be a showstopper.
Comment 1 Cluboq 2020-08-15 09:55:58 UTC
Created attachment 217229 [details]
loudgain port skeleton with gunk removal moved to post-extract target

Moved binary gunk removal to post-extract. The earlier, the better. Unfortunately, couldn't find anything like .gitignore facility in the Ports system.
Comment 2 daniel.engberg.lists 2020-08-15 10:13:47 UTC
I did some work on this earlier but didn't submit as upstream is dead/unresponsive/no longer interested.

You need to use master branch, we have taglib 1.12b1 in tree which release version of loudgain doesn't support, at least not fully.
https://github.com/Moonbase59/loudgain/commit/0e03353e6d90198204c2edd9ccf9ecaad6a8e7c8

All PRs should be added (merged) as some also includes compilation fixes for FreeBSD, on top of that you should use shebangfix for python scripts.
I would also imagine that you need to use USES= localbase for it to properly pick up dependencies.

none@FreeBSD.org as maintainer isn't correct, please set yourself as maintainer.

I'm quite sure you dont need to set multiple dependencies for the same port (ffmpeg in this case) unless you can disable required functionality which isn't true in this case as far as I can tell.

Best regards,
Daniel
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2020-08-15 10:21:19 UTC
Thank you for submitting a new port! Could you please:

- Update the attachment format to a unified diff against the ports tree root
- Confirm the changes pass QA (portlint, poudriere in particular)
- Update per review items in comment 2

Thanks!
Comment 4 Cluboq 2020-08-15 11:58:03 UTC
I am not using shebangfix because I don't include Python scripts in the installation. The reason: they rely on a publicly unavailable tool (bpm-calc) as a runtime dependency.

As for multiple library dependencies provided by the same port, what if they are made into separate ports sometime? Being a new to the Ports and packages frameworks, I am unsure if all the required shared libraries will land in pkg database unless I explicitly state them in the port skeleton.

The rest of the points are clear to me.
Comment 5 Cluboq 2020-08-15 12:05:31 UTC
Also, the Porter's Handbook says .shar submissions are allowed. Those are certainly easier on submitters but harder on committers. Smells of newbie hazing, but I'll do the dance.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2020-08-15 12:20:57 UTC
(In reply to Cluboq from comment #5)

shar's are ok, but diffs are (increasingly) preferred, and get our contributors more familiar with more of our development processes much earlier. It also reduces fragmentation/special casing.

One bonus benefit for new ports is contributors can include the part of the change that adds the port to the relevant category/Makefile 

During periods where we transition between multiple defacto standards (shar/diff -> diff for example), there's always a period of lets call it gentle encouragement

Certainly not aiming to haze, we don't do that here :)

Thanks again for submitting a new port
Comment 7 Cluboq 2020-08-15 12:31:07 UTC
Got it, will provide SVN diffs.
Comment 8 daniel.engberg.lists 2020-08-15 12:36:14 UTC
As for the ffmpeg deps question, if that happens at somepoint there will be a tree-wide PR about it.

As for reference: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/uses-python.html

https://github.com/Moonbase59/loudgain/blob/master/bin/rgbpm2 Why is that not possible to include? I agree although that naming is a bit weird haivng in mind what it actually does.
Comment 9 Cluboq 2020-08-15 12:51:55 UTC
You are right about rgpbm2, it contains no mention of the bpm-calc publicly unavailable tool. In fact, it does nothing BPM-related whatsoever. I have a good mind to put it in the examples directory, after shebangfix, of course, and, perhaps rename it.

The upstream communicated with me this spring, and wrote he would have the rgbpm script as an example.
Comment 10 Cluboq 2020-08-15 12:54:06 UTC
Also, putting ffmpeg in RUN_DEPENDS would be misleading, since loudgain doesn't require the ffmpeg binary, only the libraries.
Comment 11 Cluboq 2020-08-15 13:03:38 UTC
And if required shared libraries are not registered in the pkg database, then `pkg check --dependencies` won't detect if they are missing.
Comment 12 daniel.engberg.lists 2020-08-16 18:40:21 UTC
If you want to list all deps there's nothing stopping you but be aware that it's not common practice. I think we've covered everything so far regarding this port.