GameSentenceMiner: turning a game you already play into Anki cards

The pipeline is capture, cut, and card

The application is described as automating the process of creating flashcards while you play, sitting between your game and Anki and handling audio recording, screenshots and OCR so you do not have to interrupt your gameplay.

The mechanics of the audio step are the cleverest part. Voice Activity Detection is used to record and trim the specific voice line associated with the text, so the card gets the sentence in the character's own voice rather than a synthesised version of it. Screenshots capture the game state at the moment the line is spoken, with GIF support and black bar removal.

The other three features fill in the gaps a simple screenshot-plus-text card would leave. Mine from History goes back and creates cards from lines you have already encountered, including cutscenes, which is the feature that turns a game you played once into a vocabulary set. Multi-Line Support captures several lines of dialogue into one card using the built-in Texthooker. And AI Translation is an optional integration that provides sentence translations using your own API key.

That last one is a design decision worth noting. The translation is optional and keyed to your own account, so the tool is usable entirely without it. The README lists it under card enhancement rather than as a core feature, and the rest of the pipeline, OCR and audio capture, works without any model at all.

So the loop is: notice a line, hit a key, get a card with a screenshot, the audio of that line, and the text.

OCR is the fallback for games that refuse to be read

For games that do not have a text hook, the tool uses a custom fork of OwOCR to read text directly from the screen, and the documentation says this opens up possibilities for games that would otherwise be inaccessible for language learning and sentence mining. The author's own examples are Metal Gear Solid 1 and 2, Titanfall 2 and Sekiro, all mined using the OCR path.

The features list for the OCR section names three things. Easy Setup, because the installation is managed and you do not need to fiddle with terminals. A Two-Pass System giving clean, fast output similar to as if you had a hook. And Customizable Capture Zones, so you define exactly where text appears on your screen.

The two-pass design is the part that makes OCR viable for this use case. Reading a game screen directly produces noise: HUD elements, subtitles in the wrong place, text mid-transition, damage numbers, the game's own font rendering. A first pass detects candidate regions and a second pass reads them properly, which is what turns a stream of pixels into text you can put on a card. The claim of output comparable to a hook is a strong one, and it is the vendor's claim, but the approach is sound because games render text in known places and the capture zone lets you say where.

The alternative to OCR is the hook. The README lists the supported text sources as Agent, Textractor or the built-in OCR, and the acknowledgements name Agent, Agent Scripts, Textractor, Sugoi Hook and LunaTranslator as the sources of text hooking support. So a team with a hook-capable setup can skip the OCR path entirely.

The overlay is what makes it usable mid-game

The transparent overlay is the feature that turns a capture tool into something you can use while playing, and it is small enough to describe in three bullets.

Hovering over characters in-game shows definitions via Yomitan. You can create cards without ever leaving the game window. And there is an automatically generated Furigana display in game, which matters if you are learning Japanese, since furigana is the reading annotation over kanji.

The Yomitan dependency is worth pausing on. Yomitan is a browser extension dictionary, and the acknowledgements credit it for the integrated popup dictionary overlay. The overlay is therefore not a dictionary GSM implements, it is a dictionary Yomitan provides, surfaced in a way that fits over a game.

The same pattern runs through the rest of the acknowledgements, and it tells you what the project is. Renji's Texthooker and Saplling for the text hooking overlay, exSTATic for the stats design inspiration, Jiten, VNDB, Anilist and IGDB for the stats metadata, Jiten Reader for the reader available in the overlay, and chaiNNer for the Python integration strategy.

The Integrated Components section explains the last part of the design. This project includes modified versions of the following libraries, and the reason given is that the author got tired of submodule hell, so the libraries are included directly for easier management, with all credits going to the original authors. Three are named: the TextFeed Page from Renji-XD's texthooker-ui, OwOCR from AuroraWright, and the MeCab Controller from Ajatt-Tools.

Vendoring modified forks rather than depending on them is a deliberate choice with a cost. It removes a class of version conflicts, and it also means the project carries the maintenance of those forks.

The statistics view is what turns a capture habit into a study plan

The stats dashboard is described as tracking your immersion habits, and the three things it does are more interesting than the phrase suggests.

The Kanji Grid shows every kanji you have encountered, and clicking one shows the source sentences it came from. That is a frequency view of your own vocabulary, built from the sentences you actually met, and it doubles as a way back to the game moment when you saw the word for the first time.

The Goals feature sets daily reading targets. The Tools section cleans up and organises your mining history.

For a Japanese learner, the kanji grid is the piece that connects the two halves of the project. The capture side produces sentences with audio and context, and the stats side tells you which characters are still rare in what you read, which is the input to what you should study next.

The repository layout shows how the pieces are split, and it is more layered than the README suggests. There is a GameSentenceMiner directory holding the Python side, a GSM_Overlay directory, a texthooker directory, an electron-src directory for the Electron shell, a native directory, a build directory, a docs directory, and a scripts directory. There is also a texthook_manifest.json at the top level and a run.ps1 for Windows, plus a .python-version file and a uv.lock, both of which point to a Python-first project with a managed virtual environment.

The Python side is where the work is. The dependencies read like a specification of the feature list: faster-whisper and kaldi-native-fbank for speech, soundfile and sounddevice for audio capture, opencv-python and opencv-python-headless pinned to identical versions, oneocr for text recognition, numpy, rapidfuzz for fuzzy matching of the OCR text against known lines, watchdog for file watching, websockets for the overlay connection, flask and pystray for the local interface, and groq for the optional translation.

An Electron app with a Rust build hook and a version scheme built on dates

The packaging is unusual enough to be worth describing, because it tells you how the project is built and released.

The root package.json names the package gamesentenceminer with the product name GameSentenceMiner at version 2026.10.0, and the entry point is dist/main/bootstrap.js. The start script runs a build and then electron, so the app is an Electron application with a main process and a renderer, the renderer being built by Vite with its own config under electron-src/renderer.

The Python side is built with setuptools and setuptools-rust, which is the giveaway that there is a compiled component. The native directory and the two build scripts for Windows audio and Windows speech helpers point at what it is: a small native helper for low latency audio capture and speech recognition on Windows, built with Rust because the Python route is not fast enough for capturing a voice line as it happens.

The version numbers are calendar based. The package version is 2026.10.0 and the recent releases are v2026.10.0 from 2026-10-04, v2026.10.1-beta.6 and v2026.10.1-beta.7 from 2026-10-10. So a release is named for the month it shipped in, and betas carry a date and a sequence number. The build scripts include sync:version and sync:legacy, which is how that scheme is kept consistent between the Python package, the Electron package and the legacy assets.

The Python dependency pins are unusually tight, with most packages held to a patch range, numpy pinned to exactly 2.2.6 and opencv-python and opencv-python-headless both pinned to exactly 4.13.0.92. The pyproject explains why the two OpenCV distributions have to match: the regular distribution is required for windows-capture while MeikiOCR requires the headless one, both provide the same cv2 package, and if their versions differ, installation order can mix Python files from one release with the native extension from the other. That is the kind of comment that only exists because somebody hit the bug.

Where GameSentenceMiner is the wrong choice

Three situations rule it out.

The first is a learner who does not already play games in the target language. The tool is a capture pipeline, not a curriculum. It will happily turn the first hour of a game into flashcards, and the flashcards will be full of names, plot vocabulary and UI strings rather than the common words a beginner needs. The kanji grid and the daily goals are the parts that make it a study tool, and they only work once the capture habit exists.

The second is if you need a self-contained installation. The OCR path is a modified fork of OwOCR that the project vendors, and the dictionary lookups depend on Yomitan being installed. The project is explicit that it includes modified versions of third party libraries directly, so you are running the maintainer's fork rather than upstream, and a Yomitan lookup still needs Yomitan.

The third is a privacy or licensing question about the game itself. The tool records audio and takes screenshots of a game you are playing, and the resulting cards carry the game's text, art and voice. For a game you own that is a personal study aid, which is the intended use. For a game you do not own, or for any commercial use of the cards, the copyright position is a different question entirely, and the project does not address it.

On the practical side, the setup is a video link rather than a written guide. The Getting Started section says to download the latest release, then points at an Installation Guide on YouTube, then lists the requirements: an Anki tool such as Yomitan or JL, a text source such as Agent, Textractor or the built-in OCR, and a game. The wiki is marked as work in progress. So the documented path to a working setup is a video, which is a real friction point for anyone who wants to read their way through it.

Maintenance and the size of the dependency surface

The maintenance record is the strongest part of the project. The last push to the repository was on 2026-10-18, the repository is not archived, and the recent releases are v2026.10.1-beta.7 and v2026.10.1-beta.6 on 2026-10-10 and v2026.10.0 on 2026-10-04. A project shipping monthly release candidates with a date-based version scheme is one where the work is visible.

The licence is GPL-3.0, and the pyproject classifiers record it as GNU General Public License v3. That matters here in a specific way. The application ships with modified copies of other people's libraries, and the author is careful to say that all credits go to the original authors. Those two facts sit together awkwardly. The acknowledgements are generous and explicit, and the integrated components section names each original and the path to GSM's version, but distributing a modified copy of a GPL library inside a GPL application is fine, and distributing a modified copy of a library under a different licence inside a GPL application is a question the author has answered by attribution rather than by licence analysis.

The dependency surface is where the real operational cost sits. The Python requirements include faster-whisper, which is a speech recognition model, kaldi-native-fbank for audio features, soundfile, sounddevice, opencv in two pinned forms, oneocr, numpy, rapidfuzz, watchdog, websockets, flask, pystray, groq, and cryptography. Installing that on Windows, which is where the native audio helper exists, is not a quick pip install.

So the trade is clear. You get a pipeline that turns play time into cards with real audio and a screenshot, at the cost of a heavyweight local install, several vendored forks, and a wiki that is still work in progress. For a learner already committed to that setup, that is a good deal. For anyone starting from nothing, the barrier is real.

Editorial conclusion

GameSentenceMiner fits a language learner who plays games in the target language and wants the immersion to turn into vocabulary without a separate study session, and it fits a Japanese learner whose games do not expose text hooks. It is the wrong choice if you do not already play games in the target language, because the tool is a capture pipeline rather than a curriculum, and it is the wrong choice if you need it to be self-contained, since the built-in OCR is a fork of a third party project and the dictionary lookups depend on Yomitan. Before adopting it, read the installation guide rather than the README, since the README sends you to a video for setup, check that your Anki tool of choice is one it supports, and confirm the OCR accuracy on your own games before you build a study habit on cards it produced.

Frequently asked questions

Official sources

1. bpwhelan/GameSentenceMiner on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases