# 48tools: an Electron toolkit for Chinese live streaming platforms

> 48tools is a desktop application that records live streams and downloads videos from Pocket 48, SNH48 official performances, Bilibili, AcFun, Douyin, Kuaishou, Xiaohongshu, SHOWROOM and Weibo, and adds video trimming, merging and direct FFmpeg execution. It is a GPL-3.0 Electron app with a Chinese-language documentation site and a monorepo build.

**duan602728596/48tools** — 48工具，提供公演、口袋48直播录源，公演、口袋48录播下载，封面下载，B站直播抓取，B站视频下载，A站直播抓取，A站视频下载，抖音视频下载，视频截取，视频导出gif，视频合并等功能。口袋48的pc版，可以看成员的直播、弹幕和录播。

- Repository: https://github.com/duan602728596/48tools
- Website: https://yzb1g5r02h.feishu.cn/docx/MxfydWlNaovZ5sxsbJ5crnAlnVb
- Stars: 659 · Forks: 83
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/duan602728596-48tools

## One desktop app for many Chinese live platforms

The project description is a list, and the list is the product. 48tools provides live stream source capture and replay downloads for Pocket 48, official SNH48 performance recording and replay downloads, Bilibili live capture and video download, AcFun live capture and video download, Douyin video download, and video trimming, GIF export and merging. The README expands that into a fuller inventory: for SNH48 and Pocket 48 it covers live source capture, replay downloads, and watching Pocket 48 live and recorded content on the desktop with danmaku, the live comment overlay. Bilibili, AcFun, Douyin and Kuaishou each get live capture and video download, with the Douyin downloader accepting a video ID, an account ID, a video URL, an account home page or a share link, with one click download. Xiaohongshu and SHOWROOM get live source capture, Weibo gets super topic check-in, live recording and image download, and a video processing group offers trimming, merging and the execution of FFmpeg commands with the command saved locally. The audience is a viewer who follows several of these platforms at once and wants the recording on their own disk, which is a narrow but very real job that the official clients do not do.

## Downloads, releases and the Windows support floor

The application is distributed through GitHub releases, with a second distribution route through a Baidu netdisk index maintained in a separate documentation repository. The build badges show the platforms the project targets, with Windows 10, Windows 11, Linux and macOS listed, and the CI runs on two GitHub Actions runners, an Intel one and an ARM one labelled xlarge, which is what you would expect for a project that ships an Apple Silicon build. The support policy is stated in a note near the top of the README. Because of the Electron support policy, the software will upgrade the Electron version in the next release, and once the Electron version is greater than v22 the software will not support Windows 8 or earlier. That is worth knowing before you plan an installation on an old machine, and it is the kind of constraint that arrives on someone else's schedule rather than yours. The application itself is built with Electron, and the technology stack listed in the README is Pug, Sass, TypeScript, React, antd, Webpack, TailwindCSS and Electron, with corepack as the package manager. That is a large front end stack for a desktop utility, and it is a fair proxy for how much of this project is interface work.

## The three things you must configure before anything works

The README lists three prerequisites before the feature list, and they are the practical difference between a tool that runs and one that does not. The first is FFmpeg. You have to download FFmpeg and configure the path to the executable, and the note says the video playback feature needs this configuration and a restart of the application afterwards, which is a detail worth internalising because the app starts before the path is set. The second configuration is the App Data directory, needed for the 48 related features, which the README describes as the place where the data generated by the NetEase Yunxin SDK is stored. The third is the address of a headless browser, which is required for the Weibo super topic check-in feature. Those three items also tell you where the sharp edges are. The recording and downloading features are the core, the 48 group features lean on a third party SDK, and the Weibo check-in leans on a browser you have to run yourself.

On macOS on Apple Silicon there is one more hurdle, and the README addresses it head on. Running the app produces a warning that the software is damaged and cannot be opened, and the fix is a command run in a terminal inside the application directory.

```bash
sudo xattr -rd com.apple.quarantine 48tools.app
```

The README also gives the shorter variant with the -cr flag, which clears the quarantine attribute recursively. This is the standard remedy for the quarantine attribute that Gatekeeper adds to downloaded applications, and it is worth knowing that it is a deliberate, manual action on your part rather than a bug in the application.

## What the MCP module tells you about the direction of travel

The module list in the README is short but revealing. There is 48tools, which holds the application source, main, which is the Electron main process, help, which holds the local help files, test, which holds the end to end test code, and then three smaller entries that exist for specific reasons. There is babel-plugin-delay-require, a Babel plugin that supports on demand loading of Node modules, and postcss-plugin-remove-classnames, a postcss plugin that removes the class names TailwindCSS generated but did not use. Both of those are performance work: the first avoids paying for modules that are never opened, and the second keeps unused utility classes out of the shipped CSS. The third is snh48-mcp, described as a read only SNH48 query service that MCP clients can call. That entry is the most interesting, because it is the only programmatic surface in the project and it points at where the author expects the next kind of user to come from, an agent that wants to query live schedule and member data rather than a person clicking a download button. That it is read only is the sensible boundary for something like this, and the presence of a dedicated package for it, rather than a hidden flag in the main app, suggests it is meant to be used from outside.

## A monorepo with per module build and test loops

The repository is a monorepo with a lerna configuration, a yarn configuration, husky for git hooks and a scripts directory, and the development workflow in the README is organised per module rather than as one command. For the main module you enter packages/main and run node --run start to work on the Electron main process, or npm run dev to compile the development build of it. The 48tools module has two development styles, which is the interesting part. You can start a development server with node --run start:serve and then run the application with node --run runel:serve, or you can compile the files to local disk with node --run start and launch the application with node --run runel. The help module has the same shape, with node --run start for its local help files. The root package.json shows how the same convention applies to the top level tasks, with a build script that runs node scripts/delivery.mjs to complete the whole compilation, and separate scripts for generating the application icons from the source PNG with ffmpeg for the PNG, the Windows ico and the Linux icon, and an image2icns call for the macOS icns. A china mirror build script points the Electron and electron-builder downloads at a domestic mirror, which is a detail that tells you a good deal about who runs this project and where they run it from.

```json
    "build": "node scripts/delivery.mjs",
    "build:ci": "PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 npm run build",
    "install:ci": "PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 yarn install",
```

## The build and test sequence, step by step

The compile sequence is documented as a numbered list, and each step names the directory and the command, which is the pattern to follow when you build this yourself. The root build command runs the delivery script and completes the entire compilation. Then the main module is compiled with node --run build inside packages/main, the 48tools module is compiled with node --run build inside packages/48tools, and the help module is compiled with node --run build inside packages/help. After that, node scripts/unpack.mjs packages the software, and node scripts/clean.mjs deletes the useless files from it. The test sequence follows the same discipline. You complete the full compilation first, then you enter packages/48tools and run node --run test for the unit tests, and you enter packages/test and run node --run test for the end to end tests. The unit testing stack is jest with ts-jest, and the end to end stack is playwright with the playwright test package, and the CI scripts skip the browser download for Playwright because the CI machine does not need it. One note for developers is worth repeating because it costs people an afternoon: if the editor reports an ESLint timeout while working on the project, the README links to a specific configuration step for that, because the linter spawns a lot of node processes in a large codebase.

## Where this tool stops working

Three limits are visible in the documentation, and none of them is about the code quality. The first is the platform dependency. Every source this tool captures is an endpoint that the platform controls, and a stream URL extracted today can stop resolving tomorrow, which is the ordinary fate of tools that work against undocumented interfaces of other people's services. The second is the local tooling requirement, since without FFmpeg configured the recording and trimming side of the application does not work at all, and the playback feature needs a restart after the path is set, so a misconfigured install looks like a broken application rather than a missing dependency. The third is the licensing and distribution posture, and it is the one to think about before you install it on a work machine. The project is released under the GNU General Public License v3.0, and the README states that the software and all of its source code are bound by it, which is fine for personal use and awkward for a commercial redistribution. The documentation itself lives on a Feishu document rather than in the repository, so the user guide is in Chinese, and the source of truth for the project is the GitHub repository, with the documentation repository holding the download index.

## Conclusion

Adopt 48tools if you follow live streams or idol group performances from several Chinese platforms and want one desktop application that records them, trims the result and keeps a local copy instead of an offline download that the platform can revoke. It does not fit a team that needs a maintained, documented API, because the tool is a GUI first and the only programmatic surface mentioned is a read only SNH48 query service for MCP clients, and it does not fit anyone who cannot install FFmpeg, which the README lists as a prerequisite. Before you rely on it, set the FFmpeg path and restart, because the playback feature only works after that, and expect the platform side to move under you, since each source is an undocumented endpoint that a platform can change at any time.

## FAQ

### What can 48tools record and download?

Live streams and replays from Pocket 48 and SNH48 official performances, Bilibili, AcFun, Douyin, Kuaishou, Xiaohongshu, SHOWROOM and Weibo, plus Weibo super topic check-in and image download, and video processing such as trimming, merging and direct FFmpeg command execution.

### What do I need to configure before using 48tools?

The README lists three: download FFmpeg and configure its path, with a restart needed for the video playback feature; set the App Data directory used by the 48 related features to store data generated by the NetEase Yunxin SDK; and set the address of a headless browser for the Weibo super topic check-in feature.

### Why does 48tools not open on an Apple Silicon Mac?

The README says the app may report that it is damaged and cannot be opened, and gives the fix as running a command in the application directory, either sudo xattr -rd com.apple.quarantine 48tools.app or the shorter sudo xattr -cr 48tools.app, then launching it again.

### How is 48tools built and tested?

The root build command runs node scripts/delivery.mjs, then each module is compiled with node --run build in packages/main, packages/48tools and packages/help, after which node scripts/unpack.mjs packages the software and node scripts/clean.mjs removes unneeded files. Unit tests run with node --run test in packages/48tools and the end to end tests with node --run test in packages/test, using jest with ts-jest and playwright.

### Which platforms does 48tools support and under what licence?

The build badges list Windows 10, Windows 11, Linux and macOS, and the README notes that the next release will upgrade Electron, after which Windows 8 and earlier will not be supported. The software and all source code are released under the GNU General Public License v3.0.

## Sources

- [duan602728596/48tools on GitHub](https://github.com/duan602728596/48tools)
- [License: GPL-3.0](https://github.com/duan602728596/48tools/blob/main/LICENSE)
- [Project website](https://yzb1g5r02h.feishu.cn/docx/MxfydWlNaovZ5sxsbJ5crnAlnVb)
- [README](https://github.com/duan602728596/48tools/blob/main/README.md)
- [Releases](https://github.com/duan602728596/48tools/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/duan602728596-48tools