NAM to NAMB converter

Nothing you choose here leaves your browser. A Neural Amp Modeler capture is JSON — every weight written out as decimal digits — and .namb is the same model as bytes. Real captures come out around 83–93% smaller, and a device can read one without a JSON parser at all. This page does the conversion here, on your machine, and tells you what the conversion throws away before it does it.

An A2 capture cannot be converted whole, and here is why

This is the thing to understand before you convert anything. An A2 file — architecture SlimmableContainer, format version 0.7.0 — holds two complete models of different sizes, and the player picks between them while you play depending on how hard the input is driving it. A .namb file holds exactly one model. The format defines four architecture numbers — Linear, ConvNet, LSTM and WaveNet — and there is no container among them.

So converting an A2 capture means choosing one of its models and discarding the other. There is no version of this that keeps both. The reference converter refuses to run at all unless you tell it which one you want; this page shows you both, with their sizes, and makes you pick. The one you do not pick is gone from the output.

What else the conversion throws away

A .namb metadata block is 48 bytes and it holds five things: the format version, the sample rate, the loudness, and the input and output levels in dBu. Everything else a capture carries — its name, the make and model of the gear, the gear type, the tone type, who captured it, which trainer was used, the date, and the gain figure — is not in the format anywhere. It is not compressed or shortened. There is nowhere to put it.

On the real captures this was built against that is eight or nine fields out of twelve. The page lists the ones your particular file will lose, by name, before you download anything.

The weights change too, though far less dramatically: a .nam prints them at full double precision and .namb stores 32-bit floats. That is the format's design, not a shortcut taken here, and the page reports the largest difference it measured between what went in and what came back out.

How far this has been checked, and where that stops

Worth being plain about, because a .namb file can end up on hardware. Every byte this page writes is ported from the format's own source: namb_format.h for the constants, the CRC and the reader, and nam2namb.cpp for the writer. The activation type numbers are the declaration order of the enum in the NeuralAmpModelerCore header, read from that header rather than guessed.

Three things were checked. First, the layout was compared against get_dsp_namb.cpp — the loader that actually reads these files on a device. It is a separate file written for the opposite job, and it reads every field in the same order and at the same width this page writes them. Second, every file this page produces is read back in and verified before you are offered a download: if a field came out at the wrong width, the rest of the block runs off its rails and the page refuses rather than handing you the file. Third, the checksum was tested against the published check value for CRC-32/ISO-HDLC.

And here is what none of that proves. The output has not been compared byte-for-byte against the reference nam2namb tool, because no compiled copy of it and no published .namb file exists to compare against — there is not one in either repository. Reading a file back with a reader written from the same sources cannot catch both being wrong in the same way. If you are putting a converted file on hardware, load it once and listen to it against the original before you rely on it.

What .namb is actually for

A pedal or a plugin loading a .nam has to carry a JSON parser and turn a few hundred thousand characters of decimal digits into floating-point numbers before it can make a sound. On a desktop that is a shrug. On a small processor with a fixed memory budget it is the difference between loading in a moment and loading slowly, or not at all. A .namb is a 32-byte header, a 48-byte metadata block, a short description of the model's shape, and then the weights as raw bytes the processor can use directly.

Where to go next

• NAM inspector — read a capture without converting it
• amp dating — the serial number on the real thing
• pedal dating — the same for pedals

What this does not do

It converts one way. There is no .namb back to .nam here, because the metadata a capture carries is genuinely gone once converted — a file built back the other way would be missing its name, its gear and its date, and would look like a capture while not being the one you started with. It also cannot convert an A1 capture into an A2 one: the weights are the trained parameters of one particular network, and no arithmetic turns one architecture's weights into another's.

Nothing is uploaded, so it cannot read a file that is not on the device you are using, and it does not remember what you opened.