EternalBox - Local Client
Added 2020-05-18 04:54:50 +0000 UTC
So a lot of people have been asking for a local/app version of the Eternal Jukebox, and it's something that I want to facilitate when possible. Unfortunately, it's a very large undertaking, and it's something that I want to get right if I'm going to do it.
So, when I began work on the latest rewrite, I made a decision to switch to using Kotlin/JS for the front-end code. This means that there will be a slightly heavier initial load, but considering we're loading megabytes of audio into your browser I don't think that's a massive concern.
The main advantage of using Kotlin/JS though, is that I can actually reuse that code in other places. See, Kotlin/JS is part of the Kotlin Multiplatform architecture, which means I can take that code I've written in Kotlin, and compile it for Java, JS, even mobile clients. Instead of rewriting the mixing code three or four different times, I only have to write it once, make sure it works, and then I can distribute it to as many targets as I need. (This also means I'm working in a language I'm comfortable with, which *does* make things easier.)
So, after a few days of debugging, I've managed to cobble together a *very* primitive version of this in the form of a local client that can remix audio, and spit out a "10 minute" version of any Spotify song. It's, uh, not really good enough to release yet (and there's a few issues before I even do that), but I *am* working towards that goal. Main issue at the moment is it writes... uncompressed PCM audio, which for those of you who *don't* know, is very very inefficient for space. This 14 minute loop ended up being about 150 MB, whereas the re-encoded version is only 8 MB. So, look forward to optimisations on that front.
Comments
While it would only be a temporary file, the problem is that that size scales linearly. Each minute is around 10 MB of audio, which means an hour is 600 MB. Something I hear every now and then is that "Why use the jukebox when there's 10 hour loops of songs on youtube", and creating that 10 hour loop would take 6 GB of space. Considering I have other plans in mind using this technology, it's easier to try and work on that here and now, rather than having to worry about it later. Also, it saves end users having to download something like ffmpeg, or download a binary with ffmpeg included which adds 50 MB easily (Edited bc Patreon cut me off early)
2020-05-19 00:35:20 +0000 UTCi'm not sure how big an issue the space would be, i assume it would be a temporary file? or you would keep it for future re-use? maybe have an option to save it and then compress it also, looking very much forward to this!
rapchee
2020-05-19 00:16:55 +0000 UTC
