needle VS macports-ports

I used this wrapper to implement an opening and ending detection tool for “fun” [1].

However, it seems that many programs opt to instead shell out to the ffmpeg CLI. I think it’s usually simpler than linking against the library and to avoid licensing issues. But there are some cases where the CLI doesn’t cut it.

[1] https://github.com/aksiksi/needle

I've developed a command line tool that can do this for you: https://github.com/aksiksi/needle. You can try it out by downloading the latest version for your platform from here: https://github.com/aksiksi/needle/releases/tag/v0.1.5.

I’ve been working on needle[1], a CLI (and associated library) that can detect openings/intros and endings/credits across TV or anime episodes. It decodes audio, fingerprints it in chunks, and then compares chunks across files to find common sequences.

Right now, it works pretty well as a CLI app. However, the eventual goal is to wrap the library in a Jellyfin plugin (C#) that handles skipping intros. I think I’ve figured how to call a C library from C#, but there is a lot of work to do to actually get a functional plugin.

[1] https://github.com/aksiksi/needle

I was curious if it was just some kind of horrific backlog but there didn't seem to be an oppressive number of PRs open, although it seems the new submissions drag their feet quite a bit https://github.com/macports/macports-ports/pulls?q=is%3Apr+i...

Also, it seems there is currently one in progress to drop the "6" qualifier on the ffmpeg binaries <https://github.com/macports/macports-ports/pull/23315/files> so it'll be fascinating to see if any new ffmpeg7 then subsequently puts the "7" back, beginning the cycle again

I don't understand how macports was able to build dmenu just fine but i can't. Here is macports's install script if it helps https://github.com/macports/macports-ports/tree/master/x11/dmenu

First, we must force our M1 Macs to emulate the terminal using the x86 architecture; I could not find any other way of compiling successfully, and for what I understand this problem is related to the fact that the ARM compiler is somewhat more strict than what one gets with x86 (source).

I know, I hear you. I'm so sorry for having you wait! I did work so hard to get it to work on MacPorts, and I'm actually in the process of merging all of my improvements to WebKitGTK+ to get it installable this way (https://github.com/macports/macports-ports/pull/11402). Additionally, there is a ton of work on a NixOS port of WebKitGTK+ (again using my work), so it should be reliably installable on macOS ASAP!

https://github.com/macports/macports-ports/blob/0c3c5e770185f4c3577b94a49170a961b88d1b98/editors/emacs/Portfile#L100-L141

For those who can't wait for homebrew, I've updated MacPorts https://github.com/macports/macports-ports/commit/4a4329dac1a3a1ea86fe1e3740d885c34f977e04.

> Godot - doesn't work

Godot has been working well for me under Rosetta (though just a small 2D project using GDScript). Godot 3.2.3 actually supports Apple Silicon[1] although there's no binary build just yet. I've recently submit a patch to MacPorts to enable native Apple Silicon[2] and have been using it since without any issues (so far).

[1]: https://docs.godotengine.org/en/stable/development/compiling...

[2]: https://github.com/macports/macports-ports/pull/9552