Proposed move of flac to github.com/ljud/flac
Opened this issue · 8 comments
To welcome contributions and collaboration with anyone from the open source community, we've been considering to move the flac repository to the newly created GitHub organization ljud (which means sound in Swedish). Anyone interested in working on audio and sound libraries, feel free to reach out to either of us, and we'll send you an invite to the new organization.
With this move, we can also take a closer look at the API of the flac package and associated frame and meta packages. Is the API well defined, consistent and as clean? Are there any parts that could be updated when we do the move.
The intention is to make a transition as smooth as possible, and we also intent to send PRs to the main game engines, music players, and other repositories using mewkiz/flac as a backend for FLAC decoding.
For now, the list of users includes (feel free to add to this list if you are using github.com/mewkiz/flac currently):
- Audio playback library: https://github.com/faiface/beep
- Azul3D game engine: https://github.com/azul3d/engine
- Music player: https://github.com/mjibson/moggio
- Example code: https://github.com/wjblack/goflacook
- Album tag checker: https://github.com/varyoo/albumpact
- FLAC tools: https://github.com/lpar/flactools
- Media content management system: https://github.com/brendoncarroll/friendflix
- Audio server: https://github.com/zenathark/astream
- Music player: https://github.com/cswank/mcli
- Music player: https://github.com/And678/goPlayer
Some users of the flac package may be located using GoDoc.org https://godoc.org/github.com/mewkiz/flac?importers
EDIT: Oh, and to keep the code running and make the transition as smooth as possible we can try using vanity imports.
Cheers,
Henry and Robin
Well, one thing to investigate would be what benefits would we garner by making the parsing / decoding pipeline(s) concurrency based with channels and go routines?
Performance wise the API passes with flying colors, since we can do live decoding (which according to me is our highest priority). It would perhaps be if we want to support mass decoding / encoding of media libraries that we would need to investigate the concurrency approach. However, the complexity and footguns from data races might outweight the risk. But, it's educational and fun so it's a tie in my opinion.
Also, I think the API is very mature and usable, but we're in short supply of a util library for common operations like extracting the VORBIS metadata from a file directly.
Good initiative,
kram
Edit: forgot the mandatory emojis 🐫 🍍 🇯🇵
Performance wise the API passes with flying colors, since we can do live decoding (which according to me is our highest priority). It would perhaps be if we want to support mass decoding / encoding of media libraries that we would need to investigate the concurrency approach. However, the complexity and footguns from data races might outweight the risk. But, it's educational and fun so it's a tie in my opinion.
I'd say for learning it would be great fun to explore. To keep the API simple and guard against race conditions, probably not worth it for the master branch; as I think ffmpeg and other projects written in C will always (where always is defined as 30 years into the future) be used for mass conversion.
If we do the concurrent approach, I think the branch should be called metalstorm, and the aim being to beat ffmpeg speed by pure concurrent CPU force.
Also, I think the API is very mature and usable, but we're in short supply of a util library for common operations like extracting the VORBIS metadata from a file directly.
Yes, the API feels quite mature. We can take a swoop through it, and clean up small edge cases. Perhaps when we meet this summer!
I'm about to order tickets btw 🌸, we can talk more about details if we Skype this weekend.
kraam
I'd say for learning it would be great fun to explore. To keep the API simple and guard against race conditions, probably not worth it for the master branch; as I think ffmpeg and other projects written in C will always (where always is defined as 30 years into the future) be used for mass conversion.
I agree. Because, if we want the real benefits of concurrency we probably would need to expose a channel in the API which would make the library harder to use.
If we do the concurrent approach, I think the branch should be called metalstorm, and the aim being to beat ffmpeg speed by pure concurrent CPU force.
Spik! 🤘 🌩️
Yes, the API feels quite mature. We can take a swoop through it, and clean up small edge cases. Perhaps when we meet this summer!
Sounds like a good hackathon! Yeah, we'll take about tickets on Skype.
kra{3}m
kra{3}m
Älskar dig bror!
I didn't see ljud til just recently.
Is it for swedes? Are there other things that may move there?
No, it's just the name that's in Swedish. Everyone is invited to contribute!
We discussed that future implementations of audio codecs would be placed there, and util functions such as waveform visualization might also qualify.
Great! Is there a recording somewhere of the word "ljud"? I don't know how to pronounce that :)
I have a waveform viewer that animates waveforms in an html5 canvas via a server backend. It is still pretty messy in terms of configurability, but it or some parts of it may be worthy of your consideration.
For codecs, good luck! zikichombo.org/codec has had some problems getting codec implementations together in one place. If ljud could consolidate that better, it might be of interest for zc to use ljud. Going down that road, it would also be easier for all if some collective licensing organisation could be arrived at, see here.
Great! Is there a recording somewhere of the word "ljud"? I don't know how to pronounce that :)
At the specific time stamp, he says oönskat ljud, which translates to unwanted sound. So simply listen to the second word and you know how to pronounce ljud :)
https://www.youtube.com/watch?v=vQIowVg3x68&feature=youtu.be&t=116