I think I should explain one thing upfront which might clear up some of the confusion: OpenMPT tries to be smart (maybe too smart?) about which sample format it offers by default in the dialog, which is not always the one chosen in the configuration dialog: After loading a file, OpenMPT will deduce the format to use from its filename, but only (until now) if it ends in .wav or .flac (as of r16474 it also takes S3I into account). I'd be hesistant to add .raw to that logic because I think that most people, after loading a raw sample, wouldn't want to keep the sample in raw format, but rather convert it to WAV and FLAC, so that they can keep the middle-C frequency, loop points, etc... I totally get your use case but I think that defaulting to RAW format in this case would be dangerous (many people don't even realize how they could change the format from the dropdown in the Save As dialog...). Note that this logic no longer applies if a sample has been saved once, as then OpenMPT knows its new filename.

r16474 does two more things: It adds .sam to the list of raw sample extensions, and adds S3I to the list of default formats in the config dialog.

OpenMPT coerces the ".raw" extension when exporting raw

This is essentially a bit of a workaround for some of Windows' own smartness when it comes to deducing the correct filename. IIRC when you manually enter a filename but leave out the file extension, Windows will not always add the correct file extension when hitting the Save button, if the filename looks like something that already has a valid file extension. This again can cause a lot of confusion because now your sample that you just saved doesn't show up in the sample browser because it uses a bogus file extension.

I'm open to suggestions how this could be improved but I wouldn't want to hurt the default behaviour for users without this specific usecase.

OpenMPT tries to be smart (maybe too smart?) about which sample format it offers by default in the dialog [...]

OK, that makes sense. I didn't try explicitly adding any of the raw extensions to the filename or sample name before, but they also all default to FLAC as you mentioned. I don't have any ideas here aside from maybe a config option to opt-in to keeping the raw format for raw or unrecognized extensions.

Side note: ".wav" selects FLAC, but "a.wav" selects WAV. Off-by-one?

This is essentially a bit of a workaround for some of Windows' own smartness when it comes to deducing the correct filename. IIRC when you manually enter a filename but leave out the file extension, Windows will not always add the correct file extension when hitting the Save button, if the filename looks like something that already has a valid file extension. This again can cause a lot of confusion because now your sample that you just saved doesn't show up in the sample browser because it uses a bogus file extension.

I'm open to suggestions how this could be improved but I wouldn't want to hurt the default behaviour for users without this specific usecase.

I agree that nothing here is worth changing if doing so would affect general users (worst case I'll just cope and occasionally whine about it). A couple of thoughts that aren't necessarily mutually exclusive:

• Would whitelisting the other raw extensions for raw export be viable? Exporting ".snd", ".pcm" also appends ".raw", even though they're in the raw extension list. This doesn't do anything about filenames like "DigiHarp" or whatever.
• A second raw export option instead that just uses whatever filename the user provides, "Other uncompressed audio"? This might be perceived as unnecessary clutter.

Side note: ".wav" selects FLAC, but "a.wav" selects WAV. Off-by-one?

File name tokenization (a reimplementation of splitpath) treats ".wav" as the filename and not the extension in that case, that's why.

Would whitelisting the other raw extensions for raw export be viable?

I'll look into that, seems like the most sensible option for me.

maybe a config option to opt-in to keeping the raw format for raw or unrecognized extensions.

I'm dumb, this already exists. Still used to the general lack of options MPT 1.16 had...

You know, I think I have an idea. As we already have a way to force loading samples as raw, maybe adding another option to force saving samples as raw might do it - at least for individual samples (or would it be useful for you to have "Save All as Raw" as well?). So just like there's a dropdown menu item to load raw samples, I'd add one to the save icon. That would solve the whole extension mess. What do you think?

I've been thinking about this again in another context, and think that the last option I mentioned could be very useful for another reasons as well - instead of overloading the existing save dialog will all sorts of RAW options, a dedicated "Save as raw" file dialog could offer options to save as signed/unsigned/delta samples.

Sorry, I didn't realize this was still open with a pending question—yes, adding a "Save as RAW" option to the save dropdown would probably sufficiently fix this issue for me.