QAAC On Android? Is possible?

[jhonsilver19]

is it possible to use qaac on android? because there is ffmpeg encoder for android

[NeedsMoar]

This would probably be easier to build for android since there's a visual studio solution file and visual studio can target android if you install the cross tools. I'm guessing just adding it as a target would be enough to get things working. You'd need to run that in termux or write a java wrapper program to call it but just doing a java program that calls out to the executable with given parameters like the ffmpeg UI one does shouldn't be hard.

I don't know what ffmpeg has to do with it though, that's sort of like asking whether I could use 3D Studio Max natively on Linux because there's a native Maya build.

[milahu]

i have started porting qaac to unix in qaac-unix
ideally, this will work on linux, android, bsd, ... spoiler: does not work yet

im not sure if this will ever work without the closed-source dll files from itunes
which are currently used by qaac-wine (arch linux, nixos linux)
ASL.dll CoreAudioToolbox.dll CoreFoundation.dll icudt62.dll
libdispatch.dll libicuin.dll libicuuc.dll libsoxconvolver64.dll libsoxr64.dll objc.dll
maybe load them with loadlibrary, maybe reverse them...

anyway, the quickfix is to run qaac64.exe in wine
but no idea if that works on arm cpus

Running Linux program using Windows DLL (winelib) without wine?

Very few Android devices run on x86 processors. Zero Windows apps are written for ARM CPUs (the dominant CPU architecture for Android).

Ergo, you cannot use a Windows DLL on the vast majority of Android devices, regardless of WINE.

so for arm cpus, you will need an x64 emulator like qemu

[NeedsMoar]

That's not quite true. .NET runs on ARM and half of Windows software is .NET... and microsoft has a Windows ARM developer machine out for extremely cheap; the new compiler versions support building projects with mixed ARM / x86 source where the x86 will run through a Rosetta-like (might have even been bought out Rosetta tech) translation layer. It's primarily for stuff with x86 assembly that can't build otherwise. Wine won't be able to support that translation layer or those hybrid builds but shouldn't have an issue with anything .NET or pure arm since all the APIs are identical. MS didn't add anything special, they just wrote arm-optimized versions of everything relevant. IIRC it was regular EABI, although I'm afraid I don't really know much about arm64's ABI. Source: Me - I disassembled the entire Windows RT kernel and poured over it with a fine-toothed comb for 2 months at my last job to make sure we could safely claim compatibility with the ARM version of one of our compilers that I worked on directly afterwards. Windows RT was more restrictive than current Windows on ARM, too.

I'm kind of surprised a Mac M1 version of qaac couldn't be found and the .dylib rebuilt into a .so though. I think relocs could be translated and only the startup and termination code and some system calls would need to be changed, but I'm less familiar with the intricacies of silly differences between any unix system calls that might be happening. Still it shouldn't have any UI code in it which would be the huge hurdle if it was there. Or at least none that needs to be called...