-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply .aac extension so playback works in downstream Anki clients #8
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. We should potentially also look for other filetypes that would be reasonable to include. Or maybe there is a library that does this task which would be better to use.
Holding on merging for a bit until we have the project fully setup.
I think simply adding support for problem-cases as they come is the best approach for this. The current code covers all of the widespread audio formats. Outsourcing this to a library would likely be more hassle than it is worth. The reason being that 'file types' for media do not one-to-one correspond to file extensions (which are also handled differently by the end media player). As such, the file extension needed (for programs that don't properly detect the container and encodings used or otherwise override that information with the 'hint' from the file extension) will vary (because in the current landscape of feature-full, complex containers the problem is more on their side). I.e. a general solution to this is impractical as it depends on the quirks in player's implementations. Currently, the only other addition that I predict could be necessary is extending handling of opus (a more modern encoding used in ogg containers, the successor to vorbis, and becoming the standard 'backend' format (i.e. if audio is intended to be streamed, it is probably using opus)), which is already partially supported through Table with some standard extension-mime-type pairs As a heads-up and note on the original problem |
@yuki-tsubaki Thanks for providing the background and reasoning! I looked a bit into a library like https://github.com/broofa/mime, and while it does seem to largely cover everything we have, there are some very minor differences (e.g., |
Bumps [fake-indexeddb](https://github.com/dumbmatter/fakeIndexedDB) from 4.0.0 to 4.0.1. - [Release notes](https://github.com/dumbmatter/fakeIndexedDB/releases) - [Changelog](https://github.com/dumbmatter/fakeIndexedDB/blob/master/CHANGELOG.md) - [Commits](dumbmatter/fakeIndexedDB@v4.0.0...v4.0.1) --- updated-dependencies: - dependency-name: fake-indexeddb dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
From ctpk: