[ac3forge] New port

[iainchesworth]

Adds a new port for ac3forge: a clean-room
AC-3 (ATSC A/52) / E-AC-3 encoder and decoder with a spatial (Dolby Atmos-style) object layer,
in C++23. This port installs the library only (ac3::forge, plus matroska::matroska/
mp4::mp4/mpegts::mpegts behind their own default-on features) - never the project's CLI or
GUI. No third-party runtime dependency; vcpkg-cmake/vcpkg-cmake-config are host-only build
tooling.

• Changes comply with the maintainer guide.

• The packaged project is mature and ready for broad sharing with vcpkg users

  • Has a release at least 6 months old or 6 months of demonstrated public development
  • Is an official component of something else meeting that criteria
  • Some other reason (please explain)

  Being upfront about this rather than checking a box that doesn't apply: the repository is
  9 days old as of this PR and does not meet the 6-month bar. I'm submitting anyway at the
  maintainer's discretion rather than waiting, since the port itself is complete and validated
  now. If the project's age is a blocker per policy, closing this PR to revisit once it clears
  6 months is completely reasonable - no objection either way.

• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:

  • The project is in Repology: https://repology.org/project/ac3forge/versions
  • The project is amongst the first web search results for "ac3forge" or "ac3forge C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.

  Same as above - a 9-day-old project isn't indexed by Repology or ranking in search results
  yet, and the port name is the project's own name rather than an Owner-Project form. Happy to
  rename to iainchesworthlabs-ac3forge if that's preferred.

• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE

• The versioning scheme in vcpkg.json matches what upstream says. (version-semver, matching the project's own git-tag-derived SemVer.)

• The license declaration in vcpkg.json matches what upstream says. (GPL-3.0-or-later, matching LICENSE.)

• The installed as the "copyright" file matches what upstream says. (vcpkg_install_copyright(FILE_LIST "${SOURCE_PATH}/LICENSE").)

• The source code of the component installed comes from an authoritative source. (vcpkg_from_github() against the project's own iainchesworthlabs/ac3forge GitHub releases.)

• The generated "usage text" is brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct. (A custom usage file is included since the port has three opt-in features worth calling out explicitly.)

• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.

• Exactly one version is added in each modified versions file.

[Billy O'Neal (BillyONeal)]

• Being upfront about this rather than checking a box that doesn't apply: the repository is
  9 days old as of this PR and does not meet the 6-month bar. I'm submitting anyway at the
  maintainer's discretion rather than waiting, since the port itself is complete and validated
  now. If the project's age is a blocker per policy, closing this PR to revisit once it clears
  6 months is completely reasonable - no objection either way.

Unfortunately I don't see any reason to make an exception here. Additionally, GPT 5.6 Sol reports:

• The project does not yet satisfy the curated-registry maturity policy. Its public development and releases are only days old, all releases are prereleases, and no equivalent maturity basis has been established.
• ports/ac3forge/vcpkg.json default-enables matroska, mp4, and mpegts, although each feature adds a distinct public API, CMake target, import library, and DLL. Additive components may remain features but must not be enabled by default.

(Billy, not GPT note here) See https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#default-features-should-enable-behaviors-not-apis

• Azure build 136223 regresses on the upstream-supported x64 and arm64 Linux configurations. src/signing/src/signing_key.cpp uses std::uint32_t without directly including <cstdint>.
• The port does not constrain unsupported 32-bit Android targets, where the matroska feature fails because 64-bit size limits are compared with 32-bit size_type. Upstream documents only arm64 Android support in docs/platforms/android.md; either fix the implementation or add an appropriate supports constraint.
• The GPL-3.0-or-later declaration in ports/ac3forge/vcpkg.json exceeds the grant in upstream README.md, which specifies GPL version 3 without an “or later” option.
• ports/ac3forge/portfile.cmake leaves dependency-bearing options uncontrolled. In particular, src/audio/CMakeLists.txt auto-detects ambient ALSA and PipeWire installations. AC3FORGE_BUILD_ADM and AC3FORGE_ENABLE_TRACY must also be explicitly disabled to prevent undeclared discovery or fetching if upstream defaults change.
• The added ports/ac3forge/portfile.cmake and ports/ac3forge/usage files use CRLF rather than the required LF line endings.
• The portfile contains excessive and stale commentary, including staging instructions in ports/ac3forge/portfile.cmake and obsolete hash speculation in the same file. Retain only comments that explain non-obvious packaging decisions.

[iainchesworth]

Thanks for the thorough review - went through each point:

• default-features: removed. Agreed this is required policy, not optional - each of matroska/mp4/mpegts adds a distinct public API/target/binary. A plain vcpkg install ac3forge now installs the codec only; vcpkg install ac3forge[matroska,mp4,mpegts] opts in.
• Linux CI failure: real bug, confirmed and fixed upstream - std::uint32_t in signing_key.cpp had no <cstdint> anywhere in its include chain, working only by incidental transitive inclusion.
• 32-bit Android: added "supports": "!(android & !arm64)". Upstream only ever documents/builds arm64-v8a; other Android architectures aren't a real target, matching what you found (a tautological size comparison once size_t is 32-bit).
• License mismatch: GPL-3.0-or-later was the intended grant - fixed upstream's README wording, which was missing the "or any later version" clause, rather than downgrading vcpkg.json.
• Uncontrolled options: added explicit -DAC3FORGE_BUILD_ADM=OFF -DAC3FORGE_ENABLE_TRACY=OFF -DAC3FORGE_WITH_ALSA=OFF -DAC3FORGE_WITH_PIPEWIRE=OFF. Confirmed src/audio/ is add_subdirectory()'d unconditionally (gated only on not-Emscripten, not on CLI/GUI), so this library-only build genuinely was probing ambient ALSA/PipeWire without those pins.
• CRLF line endings: checked the actual committed blobs directly from GitHub - both files are LF, 0 carriage returns. Not able to reproduce this one; happy to look again if you can point at what triggered it.
• Excessive/stale commentary: trimmed to non-obvious packaging decisions only, including dropping the SHA512-provenance note you flagged.

One more thing found while re-validating locally: this port's AC3FORGE_INSTALL_BOTH_LINKAGES=OFF configuration also collided with a separate, real bug in a new C API module upstream (its export set unconditionally requires a target that isn't exported in single-linkage builds). Rather than exposing something broken, I excluded it here (-DAC3FORGE_BUILD_CAPI=OFF) and I'm tracking the actual fix separately upstream.

Also bumped to the now-current v0.8.0-beta.2 tag and re-ran x-add-version.

Still an open question on the maturity policy - no argument there, entirely your call whether that's still disqualifying regardless of the above.