Installing

Download the installer or the portable build from the latest release. Windows 10 or 11, 64-bit.

The installer puts GoodBit in your own user folder, so Windows does not ask for an administrator, and it keeps itself up to date. The portable build is a single executable you can run from anywhere; it uses the same library and settings, and does not update itself.

GoodBit and OBS

GoodBit does not record anything. OBS does: it holds the last thirty seconds of your game in memory and writes them to a file when you press a key. GoodBit is everything after that, and three things have to be true before a single clip appears.

1. OBS's replay buffer is running, and a key saves it.
2. OBS writes where GoodBit watches, the same folder for both.
3. Each clip lands in a folder named after the game, because here that folder name is the game name.

The third is not something OBS can do. Its filename format takes the clock and the video settings and nothing else, with no token for the game in front of you, so left alone it drops every clip into one folder and the whole library reads as a single game. The usual answer is an OBS script, and GoodBit can install and configure one for you.

Settings → Recording reads OBS's own configuration and says, in a sentence, which of the three is wrong. The same screen sets it up, and so does the first run. There are two routes: Quick, which takes sensible answers and shows you what it decided, and Step by step, which asks.

What it does, given the chance:

• Installs OBS if the machine has none, from the OBS project's own release. Windows asks for permission; there is no installer to click through, and no auto-configuration wizard afterwards.
• Makes a profile and a scene collection of its own, both called GoodBit, with the replay buffer on, a key bound, and your screen's real resolution and frame rate rather than OBS's 1080p30 default.
• Records in HDR when your screen is in HDR, with an encoder that can do ten bit. An HDR display recorded as standard colour is clipped in the file itself, and that is the washed out look nothing can undo later.
• Captures the game and the screen, so a clip of a browser or a windowed game is not black, plus whichever audio devices you pick, each on its own fader.
• Records into a staging folder, so GoodBit can file each clip under the game that was in front while it was recording. Nothing runs inside OBS to do it.

It never edits a profile you made, never changes which profile OBS opens with, and shows every file and key it would touch before it writes anything. Undo is in the same screen. There is a guide with both routes, the button and by hand.

First run

The first run walks the same ground: what GoodBit is, the folder both programs share, OBS itself if it is missing, and then the recording setup. Everything past the folder can be skipped and picked up later in Settings.

The folder is the one thing it cannot guess. In OBS that is Settings → Output → Recording → Recording Path, or the replay buffer path if you keep those separately.

It then scans what is already there. A few hundred clips take a minute or two the first time, most of it spent making thumbnails. After that, new clips are picked up one at a time as they appear.

Two settings are worth knowing on day one, both under Settings → App:

• Start with Windows, on by default. GoodBit's job is to have indexed the clip before you go looking for it, which it cannot do if it is not running.
• Keep running in the tray. Closing the window leaves the watcher going. Quit from the tray icon when you want it gone.

Folder layout

One folder per game, clips inside it. This is what OBS produces when the filename format includes the game, and the top-level folder name is what GoodBit takes as the game:

C:\Users\you\Videos\
  Battlefield 6\
    Battlefield 6_06.09.2026_20-53-57.mp4
    Battlefield 6_30.08.2026_21-03-56.mp4
  Ready Or Not\
    Ready Or Not_05.05.2026_22-25-52.mp4
  .goodbit-cache\        <- thumbnails and frame strips, made by GoodBit

Anything nested deeper than one folder is ignored, as is any folder whose name starts with a dot. .mp4, .mov and .mkv are recognised.

Renaming a game inside GoodBit does not rename the folder. It sets a display name, so OBS keeps writing exactly where it was and nothing needs reconfiguring. The same goes for clips: the name you give one is a label, never a file operation.

A game you would rather not see can be hidden under Settings → Games. Hiding leaves the files alone and keeps anything already published working; it only removes the game from the browsing screens.

The library

• Grouped or grid. Grouped is the default: one heading per game per day, newest first, each with an Edit day button that sends the whole day to the editor in recording order.
• Search covers names and tags. The sidebar lists games, with a search box of its own once there are enough to scroll.
• Tags can be typed, or suggested from the filename by rules you set up under Smart Tags.
• Collections group clips across games without moving anything on disk.
• Select mode does the bulk work: tag, star, publish or delete many at once. Deletes go to the Recycle Bin.

How the highlight works

Whatever made a clip worth keeping almost always made a noise. GoodBit runs one loudness pass over the clip's first audio track and looks for the stretch that stands out most against that clip's own middle, so a quiet horror game and a loud shooter are each judged on their own terms.

• It starts early on purpose. The sound is the reaction; whatever caused it happened a second or two earlier. The suggested window opens ahead of the spike so the shot that led to it is still in the clip. It will not slide so far that it loses the loud part itself, and it will not end before it either.
• It expects the end. A replay buffer is saved after something happened. Measured across 68 real recordings, the loudest moment lands in the last tenth of a clip 24% of the time, where an even spread would put it at 10%, and in the last 40% sixty per cent of the time. The search leans that way accordingly, without ignoring a bigger event earlier.
• It stays quiet when it has nothing, which is most of the time. A moment has to stand well clear of the rest of its own clip before GoodBit will point at it. Loud is not enough: a menu screen whose music swells is 17 LU above its own median, louder in those terms than a helicopter crash, and it gets refused. About one clip in six gets a suggestion.
• It is as long as the moment needs. The loud part of a clip is usually about a second. The suggestion is that, plus a run-up and a beat after, never shorter than six seconds and never longer than ten. A fixed ten used to mean eight seconds of walking before anything happened.
• It knows what is normal for each game. A racing game is a constant engine; a quiet horror game is silence and stings. Once GoodBit has listened to eight or more clips of a game, a moment also has to beat what is ordinary for that game, so a game where everything stands out does not have every clip flagged.
• It is cheap and local. About a tenth of a second per clip, computed by ffmpeg on your own machine, cached beside the clip and recomputed if the file changes.

The listening half is audio-only on purpose, because it runs on every clip you own and has to stay at a tenth of a second. A pretrained sound classifier was tried and is not used: on real recordings its gunshot and explosion labels fired on ambient gunfire rather than on the moment, and its laughter label did not fire on people laughing over game audio at all.

For some games, it reads the screen

Loudness can only report that a clip got loud. Some games will simply tell you what happened, and where GoodBit has been taught to read one, it does, and then the suggestion arrives with its reason attached rather than a guess about volume.

• Battlefield 6 is the first, and it is the banner under the crosshair rather than the feed in the corner. The feed lists everybody's kills and would have to know your name to be any use; the banner only ever appears for a kill you got, so it filters itself. GoodBit looks for the skull, the boxed KILL beneath it, and the colour (Battlefield draws assist skulls green where a kill's is white), and all three have to agree.
• The window is built around the kill, not the loudest second, which on a clip with a kill in it is as often a reload or someone shouting elsewhere. Several kills close together become one suggestion that holds all of them: three kills inside nine seconds.
• It only runs when you open the clip, only for a game that has a module, and the answer is cached. Nothing decodes video while you are playing: that is OBS's job and GoodBit stays out of its way.
• It costs about a sixth of a second per second of footage with a GPU doing the decoding, so a half-minute clip is a few seconds. The Trim page says so while it works rather than looking stuck.
• Any monitor. Everything is measured in units of screen height from a corner or the middle, which is how a game lays its HUD out, so it lands in the same place on a 16:9 monitor and on a 21:9 one.

Battlefield 6 is the only one so far, and that is a measurement rather than an oversight. Every other game in the library that was checked (Ready Or Not, Satisfactory, RV There Yet, a handful of co-op horror games) shows status on screen but never announces the moment, so there is nothing to read and the sound remains the best evidence there is. Battlefield 2042 does announce it, but differently enough that the 6 templates do not match it, and there were too few recordings to check a second module against.

It learns from what you keep

Every trim you make is an answer to the question the analysis is asking: out of these thirty seconds, which few were worth it. GoodBit now keeps that answer, alongside what it had suggested at the time, as a row in your own library. There is also a Wrong button on the suggestion banner for the one thing it cannot infer: that a confident suggestion pointed at nothing.

Once there are around sixty of those, GoodBit fits a small model to them on its own and starts using it instead of the built-in threshold, then refits after every twenty-five new decisions, so it keeps up with you. Settings → Advanced → Suggestions shows how far along it is, what the model got right on the decisions it was not shown, and has a button to go back to the built-in rule. Nothing leaves the machine at any point; the model is a small readable file in %APPDATA%\GoodBit, and you can turn the automatic part off.

Trimming

Drag the handles on the frame strip, or take the suggestion above it. The preview loops the range you have chosen, Space plays and pauses, and the playhead on the strip shows where you are.

Saving writes a new file and keeps the original. The trim is lossless: the streams are copied rather than re-encoded, so there is no generational quality loss and it takes a second rather than a minute. The trade is that cuts land on the nearest keyframe, which is why the result can be a fraction of a second off what you asked for. GoodBit reports where it actually landed.

Deciding a clip is worth nothing is also an answer, and it is one you usually reach on this screen rather than before it. Delete Clip sits beside the save button and asks first, unless you have turned that off in Settings → Data. The file goes to the Recycle Bin, so you can still get it back from there; the name, tags, notes and marks live only in GoodBit, so the question names whichever of those this clip has before it takes them.

The editor

Two lanes. The video lane is gapless, clips sitting end to end in the order they will be rendered. The music lane is free: tracks may overlap, start anywhere, and run past the picture, which is hatched because the export cuts there.

• Add clips by clicking them in the library, or arrive with a whole day already loaded from Edit day.
• Trim to highlights puts every clip on the timeline onto its own loud moment and leaves the rest alone. The properties panel does the same for one clip at a time.
• Music lives in a folder of its own, set under Settings → App. Each track gets a volume, a fade in and a fade out.
• Undo steps over whole gestures rather than every pixel of a drag.
• Drafts save as you work and survive closing the app. They export to a file and import on another machine; only ids and edits travel, so that machine needs the same clips.

Exporting

Exports run in the background: start one and carry on, or close the dialog and come back. GoodBit uses the GPU's encoder when it finds one and falls back to the CPU when it does not.

• Crop to widescreen, vertical or square. The crop takes the middle of the frame and never scales up, so a 16:9 recording cropped to vertical stays sharp instead of stretching.
• HDR footage is tone mapped to SDR rather than dumped into an SDR container, which is what turns a bright HDR clip grey everywhere else.
• Loudness can be normalised to −14 LUFS so one clip does not arrive twice as loud as the last.
• Music is mixed in a second pass, so the picture is never re-encoded to add a soundtrack.

Sending to a phone

Open a clip and choose Send to my phone. GoodBit starts a small web server on this computer serving exactly that one file behind a 32-character random address, and shows a QR code for it. Anything on the same wifi can scan it, watch the clip and save it.

The share closes itself after thirty minutes, when you press Stop sharing, or when the app quits, whichever comes first. Only that one file is ever reachable and the address is not guessable. Nothing is uploaded: the phone is talking to your PC.

Publishing

Publishing turns a clip into a public link with a Discord-friendly embed. It needs somewhere to publish to: a small Express service in the publisher/ folder of the repository, packaged for Docker and happy on a NAS.

Put its address into Settings → App and the publish actions appear throughout the app. Leave it empty and they stay hidden, so the feature is absent rather than present and failing.

It is the one genuinely hands-on part of GoodBit, because a link anyone can open means a machine the internet can reach: a container, a forwarded port and a reverse proxy with a certificate. There is a guide for exactly that, with a quick start for anyone who has done this before and a seven-step walkthrough that writes your own domain and paths into every command for anyone who has not.

Two things the guide will insist on. The publisher needs a publish token, the same value at both ends, because serving clips is public and writing to it must not be. And if GoodBit runs on the same network as the server, give it the internal address rather than the public one: the upload then goes straight to the container instead of through the proxy, which is faster and sidesteps the upload size limit entirely.

What goes up is a compressed copy by default, about a fifth of the size, so it opens quickly for whoever you sent it to, while the file on your disk is untouched. The clip menu offers the other choice, and Settings → App has the switch. Publishing reports itself as it goes: making the copy, then uploading, with a percentage, since a couple of hundred megabytes up a home connection is not instant.

Where your data lives

The database holds the things that are not in the files themselves: names, tags, notes, collections, stars. Before a new version of GoodBit is allowed near it, SQLite is asked for a snapshot and the snapshot is opened and checked, so an update that goes wrong costs nothing. Five are kept, and Settings → Advanced lists them, takes one on demand, and opens the folder.

Deleting the cache folder is safe: everything in it is rebuilt from your clips. Deleting the database loses tags and names, never clips.

Updates

The installed build checks GitHub Releases in the background and offers the update when one is ready; installing it restarts the app. The portable build does not update itself, so download a new one when you want it.

Troubleshooting

Building from source

Node 22 and npm, on Windows.

git clone https://github.com/DarrellVS/goodbit
cd goodbit
npm install

npm run dev          # electron-vite, hot reload
npm run typecheck    # main, preload and renderer
npm run test:e2e     # builds, then drives the real app with Playwright
npm run build:win    # installer and portable build, into release/

build:win depends on the end-to-end suite, so an installer cannot be produced from a tree whose tests fail. Those tests never run in CI, since they need a desktop session and ffmpeg, and each gets a throw-away data folder, videos root and database, so a run can never touch a real library.