I was saying I was concerned their conversion process could possibly compress the data to change the sound. It’s not an unreasonable assumption considering that is what’s potentially happening with all the cheaper platforms trying to add NAM. The Fractal post did say it was altering the file in some way to get it to work for their system. So not making anything up.
Either way your whole argument is pointless if that persons post is in fact correct that other platforms aren’t reading all the data for a NAM capture and altering it. It’s a legitimate concern
First of all, that’s not what was said. They did not say they altered the file “to get it to work”. @dean701 already posted a screenshot of the direct quote above:
Second of all, nobody has accused you of making anything up, you’ve simply been asked to substantiate your claims.
Reminder: you did not use phrases like “I was concerned”, “could possibly”, “assumption”, “potentially”. You used phrases that made it seem like you stated facts: “of course”, “exactly”, “I’m sure”. You’re once again trying to rewrite history.
The issue is what you inferred from the fact that the file is compressed/altered/converted: “So of course it will probably sound slightly different”. Uhm, no. It’s not “of course” and it’s not probable hence why I’ve repeatedly asked you to substantiate that the alteration is lossy or otherwise changes the data, you know, the things that would make it “of course” and probable.
Why JSON is Larger:
Textual numbers: In JSON, the number 12345 is stored as five separate characters (ASCII/UTF-8 digits), consuming 5 bytes. A large floating-point number can take 18 bytes or more.
Structural overhead: JSON requires extra punctuation like quotes, commas, braces, and colons ({, “key”:, ,) to separate fields and values.
Repeated keys: In JSON arrays, every single object repeats the exact same field names (keys), wasting space.
Textual booleans and nulls: Words like true (4 bytes), false (5 bytes), or null (4 bytes) are spelled out fully in characters.
Why Binary is Smaller
Fixed-width and native types: Binary formats (like Protocol Buffers, MessagePack, or BSON) store numbers directly as raw binary integers or floating-point values (e.g., a 32-bit integer always takes 4 bytes, and a 64-bit float takes 8 bytes, regardless of how many digits the number has).
Single-byte values: Small integers, booleans, and null values can often be packed into a single byte or even the lower bits of an opcode.
No syntactic overhead: Binary formats use compact type tags and lengths instead of human-readable quotes and commas.
Schema references: Advanced binary formats can map keys to tiny numeric IDs or indexes after the schema is defined, meaning field names are never repeated per record.
Either way, it was explained to you that a file being changed does not necessarily mean there’s any data loss or degradation in model accuracy or sound quality.
I’m not sure why you felt the need to double down on something you can’t actually back up. Even just now you repeated “getting it to work”, again, no, the quote was just shown to you: “We convert the data to binary format so that it uses less FLASH memory to store”. It’s a storage space saving measure, not a “getting it to work” measure. There’s nothing stopping them from just using the original NAM file, but why would they? Why would they not convert it to a file that allows users to store way more NAM captures on their devices?
Anyway, we’re beating a dead horse at this point, but here’s an example of your comment being changed: TWF5YmUgdGhlIHdvcmQgd2FzIGNvbnZlcnQsIGJ1dCBlaXRoZXIgd2F5IHRoZSBmaWxlIGdldHRpbmcgY2hhbmdlZCBpbiBzb21lIHdheQo=
Believe it or not, even though it’s changed, you can be confident that a computer will reproduce your comment from that string exactly as it was originally… every time, without fail. Likewise, the Axe-Fx will reproduce the original NAM file exactly, every time, without fail.
I saw that Reddit post and video, which is here: Reddit
If this is real, that’s a proof of concept that at least NAM A2 Lite is feasible on the SHARC+ DSP and maybe not as much work as previously thought given a single person was trying to do it as a personal research project.
A single person who doesn’t even have access to the source code, pretty impressive. I wish NDSP could open up their platform a bit more to people like this.
The Axe-FX III can run 2 x NAM A2-full blocks now.
And they included curated sets from Amalgam so you don’t have to go diving through a Tone3000 black hole to start (which seems to be a complaint here from some)
