[sw005320]

The course's fine-tuning notebook, updated to the ESPnet3 API it is run
against, executed before this was opened, and named speech_recognition.ipynb
like every other notebook in that directory.

It was held back from #59 by AssertionError: recipe_dir must be set when data_src is None, reported in espnet/espnet#6724. Masao's answer there — that
it is the notebook that needs fixing, not ESPnet3 — is right: a dataset is no
longer an object the notebook hands over.

The course's second fine-tuning notebook, which fine-tuned on spoken digits
and then compared CTC decoding against the beam search, is not here. Two
fine-tuning notebooks is one more than is worth keeping working.

What had drifted

What the notebooks did	What ESPnet3 does now
from espnet3.utils.logging import configure_logging	espnet3.utils.logging_utils
from espnet3.utils.stages import run_stages	espnet3.utils.stages_utils
BaseSystem(train_config=cfg)	BaseSystem(training_config=cfg)
dataset: {_target_: __main__.FLEURSDataset, ...}	a module: recipe_dir + dataset/__init__.py with a Dataset class, and data_src_args in the config
optim:	optimizer:

The dataset one is the only interesting change. DataOrganizer resolves every
entry through load_dataset_module(), which imports
<recipe_dir>/dataset/__init__.py and expects a class called Dataset; the
config passes that class's arguments as data_src_args. So each notebook
writes its dataset to that file with %%writefile and points recipe_dir at
it — which is how a recipe in egs3/ is laid out, so what the notebook
teaches is now what a recipe does.

Also in these two

• It pinned nothing. It cloned espnet from master and installed it,
  which is a build from source in a notebook and a different API every week.
  It installs espnet[train]==202610.post1 now, like the other five. The pin
  matters more here than in an inference notebook: fine-tuning reads a config
  that the trainer's API has to agree with.
• The checkpoint was named by step number (step300.ckpt), which is right
  only until someone changes max_epochs. It loads the last checkpoint the
  trainer wrote.
• text_raw, which S2TPreprocessor does not read, is gone.

The weekly run is a smaller run, and says so

A free runner cannot fine-tune at full size. The notebook reads a few
environment variables — LIMIT_TRAIN_BATCHES and the FLEURS splits — and its
workflow sets them: two steps instead of three hundred, eight utterances
instead of a split. Unset, which is what a reader has, each is the real thing.

_run_notebook.yml grew an env_json input for this, passed to the job as a
map through fromJSON rather than interpolated into a shell line.

So its badge means less than the other five, and its label says so. A
badge shows its workflow's name, so the workflow is called
speech_recognition (short run) and the caveat travels with the badge
wherever it is pasted. The notebook's first cell and both README tables say
the same thing: green means it installs, finds its data and still agrees with
ESPnet3's API, not that the fine-tuning was reproduced. (Asked for in review,
and a fair thing to ask.)

Checked

Both were run end to end in a venv holding espnet[train]==202610.post1 and
nothing else - what CI installs, rather than a checkout:

running 33 cells ... RESULT ok Courses/CMUSpeechTechnology26S/speech_recognition.ipynb

with the same environment variables its workflow sets. check_layout.py is
clean at six course notebooks, and tests/ passes.

The README is 35 lines now: the course, the table, what the badges mean, and
credit. What was changed from the course originals, how to run these outside
Colab, and which recordings had to be replaced and why are in
MAINTAINING.md, which is where someone maintaining them will look and where
nobody opening a notebook has to.

🤖 Generated with Claude Code

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[sw005320]

Agreed, and thank you — the distinction was in the README, at the bottom,
which is exactly where nobody reads it against a green tick. It is now in the
three places the tick actually appears:

• The badge itself. A badge shows its workflow's name, so the workflows are
  named owsm_finetuning (short run) and owsm_finetuning_ctc (short run).
  The label travels with the badge wherever it is pasted, including into a
  table someone copies elsewhere.
• The first cell of each notebook, under the badges: two steps on a
  handful of utterances, green means it installs, finds its data and agrees
  with ESPnet3's API, not that the fine-tuning below was reproduced.
• Both README tables — in the row beside the badge, and then in full under
  the course table, where it also says what nothing in CI checks.

Pushed as 74fd32a. The other five keep their plain labels, so the difference
is visible in the table rather than only explained in prose.