Preset files change when no parameters have been changed

GotMetalBoy

GotMetalBoy

Power User
If I store a preset on my Axe-Fx III Mark Vintage Firmware 14.00 from the front panel by pressing Store > Enter > Enter and then save the preset file with FractalBot v3.0.5 using "Backup an individual preset" and again on the same preset press Store > Enter > Enter and save the preset file with FractalBot and then do it a 3rd time, all 3 files are different and have different MD5/SHA1 Hashes. I've attached all 3 files.

Also, I don't have any MIDI controllers or Expression pedals connected to my Axe-Fx III. I only have the USB cable connected to my PC and 1/4" outs connected to my speakers.

I've been trying to cleanup my PC and remove old backups and duplicate files and use a program called Duplicate Cleaner https://www.duplicatecleaner.com and it has an option to find similar content by a certain percentage and these 3 files match 99%. I always backup before and after firmware updates to all my gear and have accumulated tons of backups since getting my first piece of FAS gear in February 2012 which was my Axe-Fx II MK I and MFC-101 MK I. I'm grateful for all the firmware updates @FractalAudio has gifted us with but wow my backups have used up a lot of hard drive space ;)
 

Attachments

  • 59 Bassguy.syx
    48.2 KB · Views: 5
  • 59 Bassguy(2).syx
    48.2 KB · Views: 5
  • 59 Bassguy(3).syx
    48.2 KB · Views: 5
Last edited:
They have different names so of course they have different hashes. What are you trying to accompish?
 
@FractalAudio I'm just wondering why aren't the preset files the same when I made no changes to them? Why does the preset get saved differently? The Preset name is the same and the only reason the file names aren't the same is because you can't have files with the same name in the same folder.

File names aren't calculated in a file hash, just the file contents are hashed. Even NTFS alternate data streams (ADS) aren't calculated in a hash. I use NirSoft HashMyFiles http://www.nirsoft.net/utils/hash_my_files.html to calculate file hashes.

If I delete those 3 preset files and don't press Store > Enter > Enter from the front panel and just save the preset 3 times in a row with FractalBot, the files will have the same hashes. I've attached the 3 new example preset files and they all have the same hashes below:
CRC32: 0CF27500
MD5: 2B6FCA03B7FF86B3C1CEFBE24F5B168F
SHA1: 2E8914DA34532B2AAF08CF532ED82E5156EA46E6
SHA256: F0775121347D0098DB1C5365A17923FD2E95D03507DD114830A4734BC31C867C
SHA384: 4604A230CE2C4CBB6B6F6F3AA94858070FB0342282C8FCF60343FC2D1B34333C1E2B4EC784079CD022CB0A7B857F8DDF
SHA512: 85BA7B39AAE6AA396BD2C5E22BF2FA561FCC63E872A0077FB1737C25965EF14D86B25B2A5016FE4E3C7305458DB09B0D84026AEAD35395A1AFF490F128E731C2
 

Attachments

  • 59 Bassguy.syx
    48.2 KB · Views: 2
  • 59 Bassguy(2).syx
    48.2 KB · Views: 2
  • 59 Bassguy(3).syx
    48.2 KB · Views: 1
Last edited:
You could move your old backups into compressed archives (zip files). They can be compressed down quite a bit. The factory preset zip file is about 2.7 MB, yet it contains about 36 MB worth of preset bank files.
 
unix-guy said:
Perhaps there is a date/time value stored as a component of the preset content?
Click to expand...

That's what I was thinking and was hoping @FractalAudio would clarify. I know presets have different versions associated with the firmware.

If I open a .txt text document with notepad or notepad++ and make no changes and do a save as and name the file the same as the original except add a 1 to the end of the name, the new file's hash matches the original file. This is the behavior I was expecting from the Axe-FX III.
 
mr_fender said:
You could move your old backups into compressed archives (zip files). They can be compressed down quite a bit. The factory preset zip file is about 2.7 MB, yet it contains about 36 MB worth of preset bank files.
Click to expand...

After I make my full backup with FractalBot, I compress the folder with 7-zip ( https://www.7-zip.org ) as either a Zip or 7z file. 7z files are usually smaller sized but I can't open the 7z files w/o 7-Zip installed on my PC and Windows 10 has native support for ZIP files, so they open just like regular folders.

I'm not really too concerned about my backups. I'm just wondering why Axe-Fx III presets change every time they're saved if no changes were made to any parameters. I've tried exporting the presets as CSV files and comparing them and all parameters are the same but something is getting changed in the file structure every time the preset is saved, which could just be some kind of time stamp as @unix-guy mentioned.
 
Last edited:
There's a 9 byte block that's updated when you save a preset in the unit that accounts for the minor difference you're seeing. I'll guess it's a timestamp of sorts (though the unit doesn't have a user-accessible clock).

Screen Shot 2020-09-13 at 12.04.55 PM.png

(Better diff with an updated version of Hex Fiend).
 
Last edited:
iaresee said:
There's a 9 byte block that's updated when you save a preset in the unit that accounts for the minor difference you're seeing. I'll guess it's a timestamp of sorts (though the unit doesn't have a user-accessible clock).

View attachment 72725

(Better diff with an updated version of Hex Fiend).
Click to expand...

Did you save your own preset files because those aren't my files I attached but you're finding the same thing as I am. I'm finding that whenever I save the same preset with no changes, the changes in the files are at Offset 001B to 0020, 0C15, C0B3 to C0B4 and C0B6. I think the only reason C0B6 is changing is because C0B3 to C0B4 are changing and C0B6 is a checksum.

Another reason I brought this up is because I found a similar issue with my FAMC LiquidFoot+ backup files a while ago and it turned out the LF+ Editor was corrupting the backup files and was causing all sorts of problems when people would restore their backups.
 
iaresee said:
There's a 9 byte block that's updated when you save a preset in the unit that accounts for the minor difference you're seeing. I'll guess it's a timestamp of sorts (though the unit doesn't have a user-accessible clock).

View attachment 72725

(Better diff with an updated version of Hex Fiend).
Click to expand...
I went through similar explorations on Helix, similar result.

I wasn't even looking at presets but IRs, which can't even be modified in the unit or the Helix editor, and they were still different every time you saved them.

IMO, the content of preset and IR files shouldn't contain any representation of the item's name or modification datetime. That makes it possible to use standard tools to find presets or IRs that are exact duplicates, super valuable for overall management of these kinds of resources.

It's also the foundation of referencing IRs by waveform instead of location.
 
Dave Merrill said:
I went through similar explorations on Helix, similar result.

I wasn't even looking at presets but IRs, which can't even be modified in the unit or the Helix editor, and they were still different every time you saved them.

IMO, the content of preset and IR files shouldn't contain any representation of the item's name or modification datetime. That makes it possible to use standard tools to find presets or IRs that are exact duplicates, super valuable for overall management of these kinds of resources.

It's also the foundation of referencing IRs by waveform instead of location.
Click to expand...

Thanks for sharing that info! I've had my Helix Floor and Helix Native for almost a year but haven't made many backups. I think sometimes my OCD gets the best of me :(
 
This is happening because there is an unused word that has random data in it (copied from an automatic struct). This causes the CRC to change although the actual patch doesn't change.

It never occurred to me that someone would be OCD enough that this would matter. Lesson learned.
 
FractalAudio said:
This is happening because there is an unused word that has random data in it (copied from an automatic struct). This causes the CRC to change although the actual patch doesn't change.

It never occurred to me that someone would be OCD enough that this would matter. Lesson learned.
Click to expand...
Code: 
Milwaukee Tools : Woodworking Nerds
    as
Fractal Audio Gear : Guitar Tech Nerds

That'll be on an the SAT soon enough, mark my words.
 
If this affects IRs as well, then (as Dave Merrill said) it could throw a monkey wrench in the goal of using IR file hashes (or similar method) to associate IRs with presets, instead of name / IR location. ...If that is a goal. (Would be nice if it were.)

(Could I PUT any more parentheses in this post?)
 
GotMetalBoy said:
Thanks for sharing that info! I've had my Helix Floor and Helix Native for almost a year but haven't made many backups. I think sometimes my OCD gets the best of me :(
Click to expand...
If you're still using Helix, you should check out HIRB, the Helix IR Browser. Lets you see which IRs are used by which presets, and which presets use which IRs. No install, just runs in your browser, drop setlist files on it to see the results.

All modelers, or at least their editors, should have tools like that built in.

I'm zooey on TGP, the author of HIRB, though I haven't been around there much since getting my III.

I haven't used it since the changes to super referencing IRs by waveform. If the format of setlist files has changed, for that or any other reason, it may not work any more. Nobody reported problem in the TGP thread or on GitHub though, and my impression is that Line 6 tries pretty hard to keep thing backwards compatible, so it may be fine. Line 6 I think announced it in the Helix Facebook group too, might be some complaints there, dunno, don't do Facebook.
 
Last edited:
ChrisHooker said:
If this affects IRs as well, then (as Dave Merrill said) it could throw a monkey wrench in the goal of using IR file hashes (or similar method) to associate IRs with presets, instead of name / IR location. ...If that is a goal. (Would be nice if it were.)

(Could I PUT any more parentheses in this post?)
Click to expand...
Not if this word is ignored by the tools that are doing the hashing. It's only a problem using format-agnostic hashing tools against the file.
 
iaresee said:
Not if this word is ignored by the tools that are doing the hashing. It's only a problem using format-agnostic hashing tools against the file.
Click to expand...
The right fix is not to put random junk data in the file in the first place.

However, there are countless preset and bank files out there already that have it, so Fractal tools need to ignore it anyway. Generic tools will get tripped up by it, but that can't be helped at this point. Still, going forward, a string of zeros or nulls would be a better idea.
 
Dave Merrill said:
The right fix is not to put random junk data in the file in the first place.

However, there are countless preset and bank files out there already that have it, so Fractal tools need to ignore it anyway. Generic tools will get tripped up by it, but that can't be helped at this point.
Click to expand...
It's a proprietary file format. The only right or wrong is what Fractal Audio decides. Us randos on the internet don't dictate correctness here.
 
You must log in or register to reply here.
Back
Top Bottom