SeisBench: a shared API for seismic datasets, pretrained pickers and DAS models

The overhead SeisBench was built to remove

Every seismology group that trains a neural network ends up writing the same three pieces of plumbing: a loader that reads MiniSEED or HDF5 into tensors, a wrapper that applies a model to a continuous stream, and a training loop with its own normalisation and windowing conventions. None of that is science, and none of it transfers when a colleague sends you a checkpoint. SeisBench exists to make those pieces shared. The README states the goal directly: it provides a unified API for accessing seismic datasets and both training and applying machine learning algorithms to seismic data, built to reduce the overhead when applying or developing machine learning techniques for seismological tasks. The audience is therefore narrow and specific. It is for researchers who want to run an existing picker such as PhaseNet on their own station data, for groups comparing architectures on a common benchmark, and for anyone working with distributed acoustic sensing who does not want to write a DAS-specific pipeline from scratch. It is not a general signal-processing library and it is not a catalog service.

Three modules, and the boundary between them

The architecture is stated as three core modules. data holds benchmark datasets and the loading functionality around them. models holds the model collection, and the README describes three things you can do with it: create models, load pretrained models, or train models on any dataset. generate holds the tools for building data generation pipelines and, in the project's own phrasing, bridges the gap between data and models. That middle position is the interesting design decision. Rather than letting each model define its own input expectations, the generation layer sits between the stored dataset and the training loop, which is what allows the same dataset object to feed different architectures. The cost is that the generate layer becomes the place where conventions live, and any model that does not fit those conventions needs its own path. The repository is primarily Jupyter Notebook, which tells you something about how the project expects to be learned: through the examples directory rather than through a long reference manual. The Colab links in the README point at notebooks named 01a_dataset_basics, 01b_model_api, 01c_generator_pipelines, 02a_deploy_model_on_streams_example, 03a_training_phasenet, 03b_creating_a_dataset, 03c_catalog_seisbench_gamma, 03d_catalog_seisbench_pyocto, 04a_das_models and 04b_training_deepsubdas. That numbering is effectively the curriculum.

Installing SeisBench and running the first notebook

The standard route is the PyPI package, and the README's own installation line for development builds is pip install "seisbench[das] @ git+https://github.com/seisbench/seisbench. The extras marker matters: DAS support is packaged as an optional dependency group rather than being pulled in by default, which is consistent with v0.11 and v0.12 being the releases that added and then completed DAS support. The README also warns that a recently added example notebook may rely on functionality not yet part of a numbered version, and gives the git install as the workaround. That is a real constraint rather than a formality: if you follow a notebook that was merged after the last release, you are tracking main. The Python floor is 3.10, stated in the badges. Beyond installation, the material does not document configuration keys, environment variables or a settings file, so I cannot tell you what a config looks like. What it does document is workflow: clone the repository or open the Colab links, then work through the basics trio before touching the advanced notebooks. The two catalog notebooks, 03c and 03d, are worth noting because they show SeisBench being used with external associators, GaMMA and PyOcto, rather than only as a model runner.

DAS, denoising and the v0.12 release boundary

The release history is the clearest signal of where the project has been moving. v0.10.0, in August 2025, is described as adding SkyNet, SeisDAE and a more powerful model API. v0.11.0, in January 2026, is described as DAS support, performance improvements, new datasets and models. v0.12.0, in June 2026, is described as full DAS support, denoising, and more picking models. Two things follow from reading those three lines together. First, the model API was reworked in v0.10, so code written against earlier versions may not carry forward without changes. Second, DAS went from introduced to full within two releases, which is fast for a modality with its own channel geometry and gauge-length conventions. If your work is DAS, v0.12 is the first release the notes describe as complete on that front, and the two DAS notebooks, 04a for applying models and 04b for training DeepSubDAS, are the entry points. Denoising appears for the first time in v0.12 and the README files it under miscellaneous topics alongside depth estimation, which suggests it is a smaller surface than picking. I would treat denoising as the least battle-tested of the three areas, simply because it has had one release.

Where the curated approach stops fitting

SeisBench works because someone curated the datasets and the models. That is also its main limitation. If your network uses a label scheme, sampling rate or channel naming that the data module does not already handle, you are writing an adapter, and at that point you are maintaining a bridge between your format and SeisBench's conventions on top of whatever you were going to write anyway. The same applies to models. The collection is a set of implemented architectures, not a framework for arbitrary ones, and the README's phrasing about training on any dataset does not extend to training any architecture. There is a second limitation in the example workflow itself. The notebooks are the documentation, and the README concedes that recently added notebooks may depend on unreleased code. A team that pins to a numbered release and then follows a notebook from main can end up debugging a mismatch that has nothing to do with their science. The third is the licence, covered below, which is a hard boundary for some users rather than a preference.

GPL-3.0 and what it means for a model you ship

SeisBench is GPL-3.0. For a research group running experiments and publishing papers, that is usually unremarkable. For anyone embedding a picker into a product, or distributing a modified copy of the toolbox alongside their own code, the copyleft terms are the first thing to read, and the material here does not discuss how the licence interacts with pretrained weights or with models trained using the toolbox. I am not giving legal advice and the repository does not resolve that question in the README. What I can say is that the licence choice is deliberate and consistent with an academic benchmark project, and that if permissive redistribution is a requirement for you, this is a reason to look elsewhere before you invest in the API. The same applies to datasets pulled through the data module: the toolbox gives you access to them, but it does not relicense them, and each dataset carries its own terms.

ObsPy plus your own training loop, and when that is the better call

The obvious alternative is not another benchmark toolbox. It is ObsPy for reading and handling waveforms, plus your own PyTorch training code. The difference in approach is straightforward: ObsPy gives you a general I/O and signal-processing layer with no opinion about machine learning, and you build the dataset, normalisation and training conventions yourself. That is more work up front and it is the right answer when your data does not resemble the benchmark datasets, when you need a licence other than GPL-3.0, or when your architecture is unusual enough that the generate layer would be a fight rather than a help. SeisBench's value is concentrated in the cases where you want an existing picker applied to a stream, or where you want your results to be comparable to published ones on the same datasets. If neither of those is true, the abstraction is a cost. It is worth being honest that the comparison is not symmetric: ObsPy is a dependency you probably already have, whereas SeisBench is a commitment to a set of conventions that change between minor versions.

What to verify before you build on it

Maintenance looks active: the last push recorded is August 2026, three minor releases landed between August 2025 and June 2026, and the versioning is disciplined enough that the release titles tell you what changed. The upgrade cost is real but bounded. v0.10 reworked the model API, so anything written before that needs review. v0.11 and v0.12 both added datasets and models, which is additive and cheap. The DAS extras group means a plain install will not give you DAS functionality, so check that early rather than after you have written a pipeline. The practical first step is to install the package, open the three basic notebooks, and confirm that your own data can be expressed as whatever the data module expects. If it cannot, the generate module is where you will spend your time, and that is the point at which you should decide whether the shared conventions are worth adopting or whether ObsPy plus your own loop is the shorter path.

Editorial conclusion

Adopt SeisBench if your work is waveform picking, DAS or denoising on the datasets it already wraps, and you are comfortable with GPL-3.0 and Python 3.10 or newer. Do not adopt it if you need to publish a model or dataset under a permissive licence, or if your data format and label scheme are outside the catalog. Before committing, install it, run the dataset basics and model API notebooks from the examples directory, and check which pretrained weights you actually need to download, because that is the part that determines whether the toolbox saves you time or just moves the work.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. seisbench/seisbench on GitHub