TONE3000 (previously ToneHunt and TONEZONE3000)

[MirrorProfiles]

My guess is IK and Steve both deem the current aliasing performance as acceptable for what it’s trying to do. In Steve’s case I think he’d rather it’s open sourced and developed by different people in different directions.

For IK, I think it’s a case of “good enough”.

I think it’s a nice thing to improve, so long as the trade offs are minimal. I haven’t really encountered any aliasing issues with software for some time. Sometimes things can look ugly in a measurement but present minimal issues in real world use.

 

[bikescene]

I quickly reamped my Recto MW using the 50kinput48 file and the Standard file last night and trained on Tonezone3000 at the default settings.

I noticed significant output level differences (7dB) in the two training methods (uploading the reamp for the Standard vs using the Wet/Dry for the 50k file).

It’s probably user error, but I’m curious if anyone else has experienced it. The raw reamp files were at the same level. It looks like the 2nd half of the 50k wav is the Standard wav.

I ultimately was listening to the difference with Normalization on. The 50k version seemed to be slightly less bloated in the mids vs the Standard.

I was going to try to see if I could observe the aliasing in PluginDoctor but NAM crashed it on my ancient PC.

I’ll share the Tonezone links and the raw reamps here and on the FB group when I get a chance.

 

[DLC86]

I noticed significant output level differences (7dB) in the two training methods (uploading the reamp for the Standard vs using the Wet/Dry for the 50k file).

It’s probably user error, but I’m curious if anyone else has experienced it. The raw reamp files were at the same level. It looks like the 2nd half of the 50k wav is the Standard wav.

Yep, for some reason the 50k file throws off the levels calibration with the standard architecture, while it works correctly with the xSTD... I don't know why honestly

 

[bikescene]

Here are my files if any of you want to try the difference between the 50K and Standard-trained files, using the default TONEZONE3000 settings. Trained at 11.5dBu.

Recto MW Red Channel - Vintage
https://www.tonezone3000.com/outmodedelectronics/tones/mb-drmw-red-vin-test-50k-21640
https://www.tonezone3000.com/outmodedelectronics/tones/mb-drmw-red-vin-test-std-21637

Recto MW Red Channel - Modern
https://www.tonezone3000.com/outmodedelectronics/tones/mb-drmw-red-mdn-test-50k-21639
https://www.tonezone3000.com/outmodedelectronics/tones/mb-drmw-red-mdn-test-std-21636

The amp could've been set up a little better, but I was trying to get them reamped before I slept last night.

 

[2dor]

Yep, for some reason the 50k file throws off the levels calibration with the standard architecture, while it works correctly with the xSTD... I don't know why honestly

I wonder if that has anything to do with how the NAM trainer looks at the training signal & its constituent sections. I haven't trained with the new signal long enough to gauge all the differences etc but I think it's best to splice additional audio after 17 seconds into the original training signal if that's being reused. Might only apply for local training though; the ToneZone Wet/Dry pair thing might do it differently but I'm still doing things the "old" way.

 

[bikescene]

I wonder if that has anything to do with how the NAM trainer looks at the training signal & its constituent sections. I haven't trained with the new signal long enough to gauge all the differences etc but I think it's best to splice additional audio after 17 seconds into the original training signal if that's being reused. Might only apply for local training though; the ToneZone Wet/Dry pair thing might do it differently but I'm still doing things the "old" way.

View attachment 37634

I lined up the 50K file vs the v3_0_0 file. The Standard file starts at around 3:48 of the 6:58 file. It was the first time that I used the Wet/Dry training on TONEZONE3000 so I thought I was doing something wrong when I got a huge volume jump.

 

[DLC86]

I wonder if that has anything to do with how the NAM trainer looks at the training signal & its constituent sections. I haven't trained with the new signal long enough to gauge all the differences etc but I think it's best to splice additional audio after 17 seconds into the original training signal if that's being reused. Might only apply for local training though; the ToneZone Wet/Dry pair thing might do it differently but I'm still doing things the "old" way.

View attachment 37634

I'll try putting it after and see what happens

EDIT: actually, now that I think about it, the problem could be tonezone's Wet/Dry pair and not the input file, maybe this type of training just tries to match the volume of the dry and ignores the calibration?
Cuz the only profiles exhibiting this issue are those trained with that method.
Standard ones were done on tonezone too but via the sweep file (which might be identical to the CLI trainer) and xSTD on the CLI trainer.

 

[DLC86]

EDIT: actually, now that I think about it, the problem could be tonezone's Wet/Dry pair and not the input file, maybe this type of training just tries to match the volume of the dry and ignores the calibration?
Cuz the only profiles exhibiting this issue are those trained with that method.
Standard ones were done on tonezone too but via the sweep file (which might be identical to the CLI trainer) and xSTD on the CLI trainer

Confirmed, I just tried training with the wet/dry pair and the standard v3.0.0 input file and levels are fucked up as well, so that's the culprit not the super input.

Btw @2dor , could you give me a bit of help with the installation of the full nam trainer please? I successfully installed the GUI trainer, but when I type "nam-full" I get this error:

usage: nam-full [-h] [--no-show] data_config_path model_config_path learning_config_path outdir
nam-full: error: the following arguments are required: data_config_path, model_config_path, learning_config_path, outdir

And from these instructions it's not clear how I should tell nam the paths where to look for the three config files

 

[bikescene]

Confirmed, I just tried training with the wet/dry pair and the standard v3.0.0 input file and levels are fucked up as well, so that's the culprit not the super input.

That is an interesting find. I could see how the volume jump from wet/dry method could be a problem for pedal captures if they slam the next stage.

 

[BenIfin]

Just an overall general observation and comment - and thinking about perhaps "why" I.K and Steve A. didn't "fix this better" in their relative Capture Processes .... as they obviously would have known it is "an issue"

.... a few weeks ago I set up an IPad Air M1 mobile rig using an iRig Pro Duo Audio I/O using the IPad AUM Mixer app.

On it, I have the exact same Amalgam Tonex and NAM Captures for the same Amps at the exact same Captured and adjusted settings - both are using DI Captures - all Blocks and IR and settings are identical for both the Tonex iOS and GigFast Patch's

After some time A/B'ing the Tonex vs NAM versions three 3 things really strike me:-

1 => on the IPad, both set ups are absolutely rock solid - zero glitches / crashes - everything running at 48k / 32 Samples through the Interface

2 => maybe (?) there are some extremely miniscule differences in the midrange around the 2k region [which if you wanted to, all you would need to do is some micro midrange adjustments] .... but I'm not even sure if that is actually the case .... they sound and feel absolutely and completely identical

3 => whether clean, edge, crunch, rock, plexi, guitar volume at different levels etc.... to the extent that there is aliasing - which obviously there is - it is utterly un-hearable - it is completely masked by the sound/tone at any level or volume I am playing at

(1) is from a few weeks of messing / tweaking / hammering Tonex / Nam on the IPad

(2) and (3) are my subjective judgments from my own hearing - I've not run any of this stuff through any sort of spectrum analysis or meters or freq analyzers etc...

Thinking more about this, I'm reckoning that I.K and Steve A made a qualitative decision to not let "perfect be the enemy of the pretty f%cking amazing" (?)

Just my 2c observation.

Ben

 

[2dor]

Confirmed, I just tried training with the wet/dry pair and the standard v3.0.0 input file and levels are fucked up as well, so that's the culprit not the super input.

Btw @2dor , could you give me a bit of help with the installation of the full nam trainer please? I successfully installed the GUI trainer, but when I type "nam-full" I get this error:

usage: nam-full [-h] [--no-show] data_config_path model_config_path learning_config_path outdir
nam-full: error: the following arguments are required: data_config_path, model_config_path, learning_config_path, outdir

And from these instructions it's not clear how I should tell nam the paths where to look for the three config files

I don't recall the steps but IIRC it needed some files from GitHub. Anyway, I use the GUI a lot so you can rely on that. Just note that it has its own .py config file where it has its own LR and LR_DECAY values which overwrite the values in the core.py file.

 

[DLC86]

I don't recall the steps but IIRC it needed some files from GitHub. Anyway, I use the GUI a lot so you can rely on that. Just note that it has its own .py config file where it has its own LR and LR_DECAY values which overwrite the values in the core.py file.

I thought the GUI only accepted standard input files, but i guess that can be changed in the config... I'll give it a try later

 

[BenIfin]

From my layman's perspective and some Googling ....

As I understand it ..... if I am creating-sampling digital audio, and I want to ensure that I capture all frequencies through 22khz, Nyquist says I must create-sample the digital audio at twice my chosen 22khz frequency, or 44khz.

Tonex Captures are created at 44.1k (?) and NAM Captures at 48k - so alias-ed frequencies are above 22k and above 24k respectively - but we also know that things like harmonics, overtones etc.... will generate frequencies above these ranges ie:- aliasing %100 exists.

Also, the general audiological consensus seems to be that in a perfect laboratory situation, some people with literally “perfect” ears and “perfect” hearing, “may” be able to hear “something” up to 28khz

Now - when playing my digital amp gear, I always run a low and high cut … usually in the range 120hz and 4500khz … however, doing that will not un-do the aliasing / frequency folding-back already in my sounds.

So ..... putting all this together, does this perhaps explain (?) why

(a) I can see and hear aliasing in the technical examples provided but

(b) I can never hear the aliasing in the played / recorded signal due to

(a) the natural limits of my human hearing and/or

(b) the embedded aliasing is totally and completely “masked-out” by the actual guitar “sound” (?)

To put it another way ..... if any guitar Amp Sim / Capture Software / Modeler etc… is %99 perfect and %99 aliasing free .. and then it is improved so it becomes %99.5 perfect and %99.5 aliasing free, who will ever be able to “hear” or discern the difference unless they know in advance which is which .... and then you are totally in the realms of subjective pre-determined self-confirming bias.

Maybe (?) the above is why I.K and Steve A. decided not to address this issue even though they knew/know it exists (?)

That is, with the quality of Tonex and NAM, it has become, for all real-world purposes, humanly-audibly-irrelevant, even though we can technically test and show its existence.

Apologies for my very basic contribution and any errors above :)

 

[DLC86]

Starting from today Tonezone3000 offers the ability to use custom architectures! Just select "custom" and paste whatever code you'd like to use.
To use the xSTD just paste this code:

{
  "layers_configs": [
    {
      "input_size": 1,
      "condition_size": 1,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 15,
      "dilations": [
        1,
       16
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 1,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": true
    }
  ],
  "head_scale": 0.99
}

EDIT: Andrei (the russian guy who made this architecture) suggests to set these values too in the advanced settings

For standard input.wav file:
learning rate=0.0064
learning rate decay=0.0023

For 50k input file:
learning rate=0.0032
learning rate decay=0.0023

Feel free to experiment with these though, sometimes different values lead to better losses.

 

[2dor]

Starting from today Tonezone3000 offers the ability to use custom architectures! Just select "custom" and paste whatever code you'd like to use.
To use the xSTD just paste this code:

{
  "layers_configs": [
    {
      "input_size": 1,
      "condition_size": 1,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 1,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": true
    }
  ],
  "head_scale": 0.99
}

Nice stuff. Getting the formatting right was a bit of a trial & error but it seems to have stuck now.

 

[DLC86]

Nice stuff. Getting the formatting right was a bit of a trial & error but it seems to have stuck now.

Yep, basically I needed to delete the name of the architecture, make all "true" and "false" lower case and delete all the commas before a "]" or "}"
The one I posted should be good as is

 

[laxu]

Yep, basically I needed to delete the name of the architecture, make all "true" and "false" lower case and delete all the commas before a "]" or "}"
The one I posted should be good as is

A JSON validator can be useful for determining if it's valid JSON. It is picky about formatting.

 

[bikescene]

Starting from today Tonezone3000 offers the ability to use custom architectures! Just select "custom" and paste whatever code you'd like to use.
To use the xSTD just paste this code:

{
  "layers_configs": [
    {
      "input_size": 1,
      "condition_size": 1,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 8,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": false
    },
    {
      "condition_size": 1,
      "input_size": 8,
      "channels": 8,
      "head_size": 1,
      "kernel_size": 6,
      "dilations": [
        1,
        3,
        9,
        27,
        81,
        243,
        729
      ],
      "activation": "Tanh",
      "gated": false,
      "head_bias": true
    }
  ],
  "head_scale": 0.99
}

Thanks! I’m giving it a shot now and it looks like the training is going through on TZ3000.

 

[DLC86]

Edited my previous post with some additional info

 

[bikescene]

I had a little bit of time last night to reamp and applied some of the recent training info from this thread. I thought I'd share for anyone who finds it interesting.

I put a bunch of NAM files in the following folder:
https://drive.google.com/drive/folders/12ikGAk-5YSD1NhHzzDIdBO0mWHTIeark?usp=drive_link

I made captures of 4 amp channels:
-Mesa Dual Recto Multi-Watt Red Channel Vintage Mode
-Mesa Dual Recto Multi-Watt Red Channel Modern Mode
-Peavey 6505 1992 Original Lead Channel
-Vox AC15C1 Normal Channel

With the Wet/Dry method, I trained the files in the following ways:
-Standard
-xSTD code with default learning rate/decay
-My training file with some higher freq sweeps a la the 50K file + xSTD code as above

At minimum, there's 12 captures you can cycle through to hear how the different training is affected with my setup.