search

mewkiz / flac

Package flac provides access to FLAC (Free Lossless Audio Codec) streams.
The Unlicense
318 stars 44 forks source link

Proposed move of flac to github.com/ljud/flac #19

Open mewmew opened 6 years ago

mewmew commented 6 years ago

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):

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

karlek commented 6 years ago

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 :camel: :pineapple: :jp:

mewmew commented 6 years ago

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

karlek commented 6 years ago

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! :metal: :cloud_with_lightning:

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

mewmew commented 6 years ago

kra{3}m

Älskar dig bror!

wsc1 commented 6 years ago

I didn't see ljud til just recently.

Is it for swedes? Are there other things that may move there?

karlek commented 6 years ago

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.

wsc1 commented 6 years ago

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.

mewmew commented 6 years ago

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