HydrogenAudio

I got some pretty extense library of Mod Files (From the Mod Archives) with very different file extensions, and I get the error of "The Destination Format does not support floating-poin input,  the conversion will not be lossless" when I try to convert them to FLAC (Which is 24 Bit as I just learned). However It seems MP3 is 32 Bit, is it better to convert them to MP3 or FLAC? I want to mantain as close as possible to the original sound.

The best option for you will be not to convert them. A ton of space saved.

Since you use foobar2000 to try to convert, I guess you are already using https://www.foobar2000.org/components/view/foo_openmpt54

So,
* keep them as they are - you can play them, right?
* if you need to use them in other players (in-car or whatever), create low-bitrate lossies that you can throw away later

But ... if you want a lossless format that handles floating-point, try WavPack.

The best option for you will be not to convert them. A ton of space saved.

Yes you are right on this, but I want to tag them as well (not all file formats on these sound files can be done so) and also, I want them to be played by most common players and those can use either FLAC or MP3 as the most common file format. That's  why I need to to be tagged, since I can make smart playlist based on my likings and custom columns.

Since you use foobar2000 to try to convert, I guess you are already using https://www.foobar2000.org/components/view/foo_openmpt54

So,
* keep them as they are - you can play them, right?
* if you need to use them in other players (in-car or whatever), create low-bitrate lossies that you can throw away later

But ... if you want a lossless format that handles floating-point, try WavPack.

Yes, I'm already using all the possible decoding components as I can, thanks a lot still for that. Also I read somewhere about WavPack but did not pay attention to it, I though it was some kind of Music Program related to making music but why Wavpack? I have no Idea what it really does.

Also why create the low-bitrate lossies that I can throw later? If you could, explain it to me in technical terms as I really love to learn about this and I'm not very savy. Isn't the idea to have a loseless format so I don't lose the quality to the original? I know file  size is huge but I really want to listen the best quality on these sound  files but with the advantage of being able to tag it and being a common sound format.

I want to tag them as well (not all file formats on these sound files can be done so)

https://www.foobar2000.org/components/view/foo_external_tags

Also, https://www.foobar2000.org/components/view/foo_tags does much of the same thing.

I read somewhere about WavPack but did not pay attention to it, I though it was some kind of Music Program related to making music but why Wavpack? I have no Idea what it really does.

WavPack is a lossless codec, much like FLAC (it has even been around for longer), and it also supports 32-bit floating-point input (and even DSD, no other codec does that!).

WavPack is built into foobar2000 with sliders for compression settings. For the "Additional processing", level 1 appears to give good value for money, and if you are more patient, also level the quite slow 4. (5 and 6 are very slow and don't give that much extra compression.)
Stay (for now!) away from the "Hybrid Lossy" mode: WavPack can encode lossy as well, and "hybrid" means it encodes a lossy + a correction file for lossless - but until you know that this is what you want, don't use it.

That's most of what you need, but more here: https://wiki.hydrogenaud.io/index.php?title=WavPack

I though it was some kind of Music Program related to making music

It has a few plug-ins so that certain audio editors can save as WavPack rather than .wav.  That works with WavPack because it also stores all non-audio chunks of .wav files as well, so no matter how the audio editor stores "do this, do that!" into a .wav, it will be restored bitwise the same. 

(Think this way: FLAC and ALAC are audio compressors; WavPack, Monkey's, TAK and OptimFROG are WAVE file compressors.)

Quote from: arepakiller on 2022-08-11 13:54:55

I want to tag them as well (not all file formats on these sound files can be done so)

https://www.foobar2000.org/components/view/foo_external_tags

Also, https://www.foobar2000.org/components/view/foo_tags does much of the same thing.

Quote from: arepakiller on 2022-08-11 13:57:26

I read somewhere about WavPack but did not pay attention to it, I though it was some kind of Music Program related to making music but why Wavpack? I have no Idea what it really does.

WavPack is a lossless codec, much like FLAC (it has even been around for longer), and it also supports 32-bit floating-point input (and even DSD, no other codec does that!).

WavPack is built into foobar2000 with sliders for compression settings. For the "Additional processing", level 1 appears to give good value for money, and if you are more patient, also level the quite slow 4. (5 and 6 are very slow and don't give that much extra compression.)
Stay (for now!) away from the "Hybrid Lossy" mode: WavPack can encode lossy as well, and "hybrid" means it encodes a lossy + a correction file for lossless - but until you know that this is what you want, don't use it.

That's most of what you need, but more here: https://wiki.hydrogenaud.io/index.php?title=WavPack

Quote from: arepakiller on 2022-08-11 13:57:26

I though it was some kind of Music Program related to making music

It has a few plug-ins so that certain audio editors can save as WavPack rather than .wav.  That works with WavPack because it also stores all non-audio chunks of .wav files as well, so no matter how the audio editor stores "do this, do that!" into a .wav, it will be restored bitwise the same. 

(Think this way: FLAC and ALAC are audio compressors; WavPack, Monkey's, TAK and OptimFROG are WAVE file compressors.)

Thanks, you really put me out of my misery with this, was really thinking about it for a while. Hard when you don't know a thing about audio, been trying to for the last few years but my knowledge was very limited, until recently I started learning more about sampling, codecs, tags, and installing components on foobar2000 (and customizing it) that I really knew nothing of the capability of this program.

Probably will see me around here in case I get stuck with more advanced topics.

Amiga MODs mostly contain 8bit samples, there's really no need to encode to anything higher than 16bits - what are you decoding with that you get such error? Maybe some unoptimal settings in Converter...

Also keep in mind that although foo_openmpt54 keeps most attention to details, you won't get perfect output as on real Amiga - it had really weird audio chain, also in analog domain, so keeping things lossless might be a stretched philosophy here...

You might be interested in https://www.paula8364.com where they capture music on real Amiga.

what are you decoding with that you get such error? Maybe some unoptimal settings in Converter...

It is simply because the mod plugin that OP used uses float internally, so the conversion is "lossy" from the perspective of the plugin's synth engine.

Synth engines often involve fairly complex manipulation of samples like volume/pitch envelopes, mixing, panning, filtering and so on, these operations of course can be done in floating point even though the original hardware uses integer synth engine.


VSTi emulation of older synths falls into this category as well. Some audio samples attached in the post below:
https://hydrogenaud.io/index.php/topic,97746.msg1003258.html#msg1003258

(Think this way: FLAC and ALAC are audio compressors; WavPack, Monkey's, TAK and OptimFROG are WAVE file compressors.)

This is misleading. When you read "audio compressors" even in italic, "audio dynamic range compression" pops up in mind. FLAC is *.wav compressor.

FLAC is *.wav compressor.

That has been in the FAQ at https://xiph.org/flac/faq.html for years, in particular the questions:

Why doesn't FLAC store all WAVE metadata?
If flac compresses WAVE files, why isn't it technically a WAVE file compressor?
I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical. Why?
I decoded a FLAC file and the WAVE is 2 bytes shorter than the original. Why?


A file compressor gives you the file back - FLAC gives you the audio back. Decode a FLAC file to WAVE, and the decoder will decide which version of the WAVE formats to output. In some cases it might be possible to infer that the FLAC was created from a WAVE and not an AIFF, but not in general.

original hardware uses integer synth engine.

Something wants to be "better than original"...
Still, no reason to not quantize down to 16bits at most.

Something wants to be "better than original"...
Still, no reason to not quantize down to 16bits at most.

My comment was not about whether one should quantize to 16-bit or not, but about this:

what are you decoding with that you get such error? Maybe some unoptimal settings in Converter...

Because the only way to disable the "error" is to dismiss that warning message, and that warning message is not specific to any input format. The format handler reports a bit-depth to the converter and triggered the warning.

Disable the transcode warning will also affect conversion of for example, floating point .wav files to FLAC files. In this case, non-tech-savvy users will not know the conversion is not lossless.

In terms of transparency, I can't distinguish 24-bit hi-res or DSD from CDDA, so it is not a matter of mod files use low bit-depth samples or integer synth engines on original hardware. In the world of emulation, a lot of people use upscaling on those vintage NES console emulators, or apply advanced texture filtering and such on PSX emulators as well, or some GPU shaders to mimic old CRT screens.

Yes but I'm more about OP wanting to "mantain as close as possible to the original sound".
What are you using for decoding? foo_openmpt54 doesn't give me the warning for MOD files and it converts quietly to 24bit FLAC. IMO it's unfortunate if plugin for such legacy formats outputs more than 16bits - by default it should requantize to 16.

I am also using foo_openmpt54, latest version:
https://www.foobar2000.org/components/view/foo_openmpt54

You either have the transcode warning disabled permanently (see the screenshot in my previous post) or using an old version of foobar2000 without the transcode warning feature (in Preferences > Advanced). I just tried a fresh portable install of foobar2000 1.6.11 + free encoder pack + foo_openmpt54 and the same warning showed up when I encode to 24-bit flac. Transcode warnings are by default enabled, and I clearly remembered this because when the first time I got this warning, there was a spelling mistake in the warning dialog:
https://hydrogenaud.io/index.php?topic=119314.0
Screenshot of the spelling mistake:
https://www.audiosciencereview.com/forum/index.php?threads/software-player-volume-vs-dac-digital-volume-vs-analog-volume.9196/post-300770

Also, forcing the output to a specific bit-depth does not automatically mean the emulation is more accurate. Here is what I got from a real game console, notice the fading artifact (discontinuity and idle tone)  in the attached file:
https://hydrogenaud.io/index.php/topic,114247.msg941114.html#msg941114

Then listen to the sound of this video:
https://youtu.be/jBWlbax6j64?t=622
Among other things like stereo width, as an owner of the real console, I am pretty sure the original hardware is not capable of smooth fading in this game without idle tone, so it must be an emulator recording.

Merely lowering the output bit-depth of an emulator may simply introduce other artifacts, but not the identical artifacts in the original hardware. Depending on the internal state of the emulator's engine, outputting to a higher bit-depth could actually be more accurate. Some arcade games enthusiasts even collect original PCBs and cabinets. Emulators simply can't fulfill their needs.

Ok I checked other MODs and they indeed report as 32bit, I have one MOD which doesn't report any bit depth and I happened to check on this one first haha... Not sure whats so special about it, maybe it is from some simple tracker like Sound Tracker... Properties say it has RG info written in an APE tag :/ maybe this is fooling the decoder...
I have everything in the newest versions.
Anyway. There most probably are reasons to decode at higher bit depth, but at the end it would be wise to requantize to 16bits, which at these bit-depths would bring no audible artifacts, and would spare the waste of bits and confusion.

Provided 16/44 is transparent unless proved otherwise in ABX, one can convert anything to 16/44, but don't expect these emulators can always 100% replicate the real thing, no matter what rendering formats are being used. If there are audible differences when compared to the real hardware, the reasons are the emulators' codes and algorithms, or analog distortion in the case of analog capture of real hardware, not the exporting bit-depth.

Reasons of using floating point are not only for potentially higher perceived quality, but also make things simpler and faster for generic CPUs and software available these days.

Also, some tracker files I have contain >0dBFS rendered sample values, at least when using foo_openmpt54's default settings. In these cases, volume should be reduced when export to FLAC to avoid clipping.

In fact, one of the files in the screenshot I posted is from a MS-DOS game for PC, and foo_openmpt54 plays it, so the plugin itself is not specific to any particular hardware in the first place.
https://youtu.be/QUzqrmQdxRY

don't expect these emulators can always 100% replicate the real thing

Thats what I wrote in 1st post. And thats the reason why converting it to lossless or keeping at decoders' internal bit depth is questionable. Original sound was most often 8bit, sometimes 16bit - there's no point in listening to it or storing it at any higher bit depths - plugins for such legacy formats should have a requantizer at the end, with an option to disable, but by default requantizing everything to sane 16bits.

Additional codes in the plugin are needed to convert the tracker files to another bit-depth which is not native to the plugin's processing format, as foobar's converter itself already provided facilities for bit-depth conversion, there is no need to do this within the plugin.

Trackers are more or less a different form of DAW, and OP's mention of "Mod Files (From the Mod Archives) with very different file extensions" implies the files obtained are not specific to any hardware or sample format, for example, the files could be originally created with modern PC trackers. So it sounds strange that one should limit how a DAW should process samples in the first place.

Instead, I would rather let OP understand the meaning of foobar's transcode warnings, rather than talk about bit-depth of samples in the tracker files or any hardware specific things.

Wow what are DAWs doing here, man, you're making things more confusing than they already are.

It really is very simple:
Most music sources (like CDs) and listening hardware is 16bit. That you encode to lossy format like MP3 which is floating point internally, doesn't mean that you should get warnings while transcoding to FLAC that it won't be lossless because it doesn't support float32, nor should you play it back at 32bits, nor should you have info in Properties dialog that MP3 is 32bit. And you don't.

It even more applies to legacy MODs and derivatives, which mostly come from 8bit hardware and contain 8bit samples. That one gets a warning while transcoding to FLAC that it won't be lossless because it doesn't support 32bits, or that Properties say that MOD is 32bit, is a design fault of plugin or fb2k.

Sure we can share to normal people additional knowledge that some module formats support DSP, are synth capable, may benefit from internal float32 processing, or that there even are tracker-derived DAWs like Renoise where 32bits might be worthwhile for further mixing, but the main message is simple:

There's no point in converting MODs to lossless formats at bit-depths higher than 16.

doesn't mean that you should get warnings while transcoding to FLAC that it won't be lossless because it doesn't support float32

Yes you should. You should get warned when trying to encode lossily into a lossless format.
It doesn't matter that the loss is inaudible - encoding lossless is supposed to be just that (lossless), and if the user wants to downconvert, let them override.

Really? You should get the warning while transcoding internally float32 MP3 to FLAC?  :))
You don't downconvert anything from MOD to FLAC the same as you don't downconvert anything from MP3 to FLAC.

Most music sources (like CDs) and listening hardware is 16bit. That you encode to lossy format like MP3 which is floating point internally, doesn't mean that you should get warnings while transcoding to FLAC that it won't be lossless because it doesn't support float32, nor should you play it back at 32bits, nor should you have info in Properties dialog that MP3 is 32bit. And you don't.

Do you notice when you use foobar's converter to encode mp3, "Output bit depth" and "Dither" in the converter dialog are not available? When you click the "Edit" button then choose "Custom" in the drop down dialog, if you specify the format is "lossy", then foobar will treat the format as lossy, and the transcode waning will not show up. foobar of course has these presets out of the box so users don't need to manually do this, unless you are using other unpopular encoders.

As mentioned, foo_openmpt54 may render some files with >0dBFS values, so it is not only a matter of "resolution", but also compatibility. Without paying attention, casual conversion to FLAC may induce clipping, so the warning makes perfect sense: users should take care of audio level themselves.

There's no point in converting MODs to lossless formats at bit-depths higher than 16.

I'd say in terms of transparency, there is no need to convert any audio format, including generic ones like DSD and Hi-res PCM beyond 16/44 if the differences cannot be ABX'ed. The whole thing has nothing to do with MOD music at all.

You are limiting yourself to the so-called "legacy" impression of "MOD" music to some specific old hardware or software, just some examples of demos require a fairly modern computer to run utilizing tracker music:
https://www.pouet.net/

Even the foobar plugin being discussed (OpenMPT) is orginated from a modern PC tracker, see the advanced features:
https://openmpt.org/features

Really? You should get the warning while transcoding internally float32 MP3 to FLAC?  :))

Absolutely. Creating a file in a lossless format does not make for losslessness in that case.
For the same reason as MQA is not lossless - but more: float32 can exceed 0 dB, and many MP3s do. FLACs could then clip.

You should also get a warning while transcoding MP3 to WavPack even if WavPack can accommodate 32-bit floating-point.

foobar2000 lets you switch off those warnings.

Do you notice when you use foobar's converter to encode mp3, "Output bit depth" and "Dither" in the converter dialog are not available? When you click the "Edit" button then choose "Custom" in the drop down dialog, if you specify the format is "lossy", then foobar will treat the format as lossy, and the transcode waning will not show up. foobar of course has these presets out of the box so users don't need to manually do this, unless you are using other unpopular encoders.

As mentioned, foo_openmpt54 may render some files with >0dBFS values, so it is not only a matter of "resolution", but also compatibility. Without paying attention, casual conversion to FLAC may induce clipping, so the warning makes perfect sense: users should take care of audio level themselves.

That's the problem - MODs have no bit depth. Look at MP3 Properties how fb2k handles them - there's no bit depth. The same should be with MODs.
Just like with MP3 you rather handle >0dBFS with ReplayGain/DSP when transcoding, not bit depth of target format.

I'd say in terms of transparency, there is no need to convert any audio format, including generic ones like DSD and Hi-res PCM beyond 16/44 if the differences cannot be ABX'ed. The whole thing has nothing to do with MOD music at all.

We're talking about sane defaults - by default MODs should be quietly converted to 16bits so beginners like OP don't do insane things with converting them to 32bit lossless. If one has special needs of course the choice shall remain.

You are limiting yourself to the so-called "legacy" impression of "MOD" music to some specific old hardware or software, just some examples of demos require a fairly modern computer to run utilizing tracker music:
https://www.pouet.net/

Even the foobar plugin being discussed (OpenMPT) is orginated from a modern PC tracker, see the advanced features:
https://openmpt.org/features

You're talking to a guy whose tracker music was used in some games, believe me Pouet and OpenMPT are no news to me :]
No MOD in existence has samples over 16bits, no MOD in existence has been mastered for anything higher than 16bits. Yes some newer trackers may be using DSP or synth with precision higher than that, or floating point, just like MP3 internally is floating point. It doesn't change the fact that at the end you don't decode MODs or MP3 to anything higher than 16bits, unless for some special purposes. Period.

Quote from: rutra80 on 2022-08-13 13:18:47

Really? You should get the warning while transcoding internally float32 MP3 to FLAC?  :))

Absolutely.

By default fb2k doesn't give such an absurd warning, it actually warns the other way around - that converting lossy to lossless won't improve quality and will only wastefully bloat the size - and then converts to 16bit FLAC :D

That's the problem - MODs have no bit depth. Look at MP3 Properties how fb2k handles them - there's no bit depth. The same should be with MODs.

Apple to orange comparison as mp3 is not a sequencer format.

You're talking to a guy whose tracker music was used in some games, believe me Pouet and OpenMPT are no news to me :]
No MOD in existence has samples over 16bits, no MOD in existence has been mastered for anything higher than 16bits. Yes some newer trackers may be using DSP or synth with precision higher than that, or floating point, just like MP3 internally is floating point. It doesn't change the fact that at the end you don't decode MODs or MP3 to anything higher than 16bits, unless for some special purposes. Period.

It's already been mentioned many times that sample bit depth is not a valid argument. Digital processing and mixing requires a higher bit-depth than the samples themselves, even if the export target is 16-bit.

As mentioned, in terms of transparency, I don't advocate anything beyond 16/44 as conversion target, MOD or not, but the fact is software trackers these days can output high bit-depth PCM, what you believe how people make music is just your own belief. A simple example, many ASIO drivers only output to a single bit-depth (24 or 32), so even if the composer/editor don't care, they are listening to high bit-depth audio unconsciously already, if they are using a modern PC tracker with ASIO output.

People who make tracker music does not need to know how to write a tracker sequencer or renderer, they just need to know how to make tracker music.

Apple to orange comparison as mp3 is not a sequencer format.

Then you shouldn't discuss them if you can't grasp properties they share.

It's already been mentioned many times that sample bit depth is not a valid argument. Digital processing and mixing requires a higher bit-depth than the samples themselves, even if the export target is 16-bit.

As mentioned, in terms of transparency, I don't advocate anything beyond 16/44 as conversion target, MOD or not, but the fact is software trackers these days can output high bit-depth PCM, what you believe how people make music is just your own belief. A simple example, many ASIO drivers only output to a single bit-depth (24 or 32), so even if the composer/editor don't care, they are listening to high bit-depth audio unconsciously already, if they are using a modern PC tracker with ASIO output.

People who make tracker music does not need to know how to write a tracker sequencer or renderer, they just need to know how to make tracker music.

I know both while you don't seem to understand either. You're repeating obvious facts I already stated, falsely insinuating reverse meaning only to support your questionable point. Which is what anyway? That by default fb2k should warn when transcoding float32 input - therefore most lossy files - to a lossless format, that it is not lossless? Or that people should generally switch to higher bit depths for everyday use?

I don't think we're going anywhere with this "discussion". kode54 (and other fb2k module plugin devs) might reconsider if it wouldn't be more optimal to not report bit depth, just like it is with lossy formats.

Then you shouldn't discuss them if you can't grasp properties they share.

In this post:
https://hydrogenaud.io/index.php/topic,122767.msg1013631.html#msg1013631
I was talking about setting up an encoder. For example it would not make sense to have an "encoder" to encode FLAC to MOD with only a few mouse clicks. Converting mp3 to flac will trigger another warning (warn about converting lossy to lossless/hybrid), so not the same thing and has nothing to do with floating point at all because lossy formats are not necessarily floating point by nature.

When I pointed out the bit-depth properties in this post:
https://hydrogenaud.io/index.php/topic,122767.msg1013552.html#msg1013552
My purpose was to explain why the warning showed up, instead of any fidelity issue if not clipping. It is actually YOU the first one to mention that mp3 is floating point. If you want to give an example, at least use foo_midi, because it can render to 32-bit float PCM with >0dBFS values without triggering that specific warning. Many years ago when I used the MIDI plugin for the first time in Windows 7 after upgrading from XP, this gave me a lot of headache because Windows 7 with DirectSound output will go through a limiter. Lowering foobar's main volume cannot solve this issue because the limiter is inserted BEFORE foobar's main volume control:
https://hydrogenaud.io/index.php/topic,104051.msg854152.html#msg854152

On the other hand, in Windows XP with DirectSound, everything can be solved by lowering foobar's main output volume.

In fact, before I know about this, I reported the above as a foo_midi bug to kode54, and his explanation was unclear, I actually needed to figure out things myself and used ASIO as output to solve the issue before foobar has deprecated the DS output and uses WASAPI shared mode as default.

In case you don't know, the trackers files in my screenshots were randomly chosen, but all of them showed a bit-depth, and triggered that warning, that's why I pointed this out in my earlier reply.

Quote from: arepakiller on 2022-08-11 13:54:55

I want to tag them as well (not all file formats on these sound files can be done so)

https://www.foobar2000.org/components/view/foo_external_tags

Also, https://www.foobar2000.org/components/view/foo_tags does much of the same thing.

Quote from: arepakiller on 2022-08-11 13:57:26

I read somewhere about WavPack but did not pay attention to it, I though it was some kind of Music Program related to making music but why Wavpack? I have no Idea what it really does.

WavPack is a lossless codec, much like FLAC (it has even been around for longer), and it also supports 32-bit floating-point input (and even DSD, no other codec does that!).

WavPack is built into foobar2000 with sliders for compression settings. For the "Additional processing", level 1 appears to give good value for money, and if you are more patient, also level the quite slow 4. (5 and 6 are very slow and don't give that much extra compression.)
Stay (for now!) away from the "Hybrid Lossy" mode: WavPack can encode lossy as well, and "hybrid" means it encodes a lossy + a correction file for lossless - but until you know that this is what you want, don't use it.

That's most of what you need, but more here: https://wiki.hydrogenaud.io/index.php?title=WavPack

Quote from: arepakiller on 2022-08-11 13:57:26

I though it was some kind of Music Program related to making music

It has a few plug-ins so that certain audio editors can save as WavPack rather than .wav.  That works with WavPack because it also stores all non-audio chunks of .wav files as well, so no matter how the audio editor stores "do this, do that!" into a .wav, it will be restored bitwise the same. 

(Think this way: FLAC and ALAC are audio compressors; WavPack, Monkey's, TAK and OptimFROG are WAVE file compressors.)

Thanks, I started testing, and will get back to you, I tried to convert the files to .wv but the file size was huge for some reason uknown to me. I did set up the "slider" to the smallest compression mode "Extra High", and additional processing 4 to see what was the results. For some reason I'm getting huge files around 50-100 mb per file lol. Here is a pic of what it shows.

What can you recommend? Should I do another conversion from .wv to another file format? My goal is to have a file size no more than 20-30 mb per file and have those files in a popular format that can accept tags, and when converted not being significatly distored from the original file or have encoding problems due to the technical aspects that I'm not probably aware about.

Yes but I'm more about OP wanting to "mantain as close as possible to the original sound".
What are you using for decoding? foo_openmpt54 doesn't give me the warning for MOD files and it converts quietly to 24bit FLAC. IMO it's unfortunate if plugin for such legacy formats outputs more than 16bits - by default it should requantize to 16.

Hi, I refer to not only mod files, I also mean 669, AHX, AMF, DMF, DSM, FAR, HVL, IT, MDL, MED, MO3, MOD, MPTM, MTM, PLM, S3M, STM, ULT, XM for example. It's the whole library of the Mod Archives, there is many more sound files types but for the sake of time and quality conversion, since it seems WavPack is really good, seems like good choice for me since I don't have that much time to play around with different formats, I just want to put for example 3000 files in foobar and let the conversion take it's time but maintaining a similar FLAC filesize and same or better quality as FLAC.

Additional codes in the plugin are needed to convert the tracker files to another bit-depth which is not native to the plugin's processing format, as foobar's converter itself already provided facilities for bit-depth conversion, there is no need to do this within the plugin.

Trackers are more or less a different form of DAW, and OP's mention of "Mod Files (From the Mod Archives) with very different file extensions" implies the files obtained are not specific to any hardware or sample format, for example, the files could be originally created with modern PC trackers. So it sounds strange that one should limit how a DAW should process samples in the first place.

Instead, I would rather let OP understand the meaning of foobar's transcode warnings, rather than talk about bit-depth of samples in the tracker files or any hardware specific things.

Really? You should get the warning while transcoding internally float32 MP3 to FLAC?  :))
You don't downconvert anything from MOD to FLAC the same as you don't downconvert anything from MP3 to FLAC.

Yes, I totally agree and understand that from MP3 and FLAC, but both are popular and can be played with normal players, but the original sound file for example  669, AHX, AMF, DMF, DSM, FAR, HVL, IT, MDL, MED, MO3, MOD, MPTM, MTM, PLM, S3M, STM, ULT, XM are not and I want to be able to play them with a phone in something more of a popular format, and for that I need to convert them. I can lose a bit of quality, but if I do so then so be in a way that not significant, that's why I want the conversion process to be free of artifacts,  sound errors, or even conversion errors. But also I want to be able to get tags embeded into the file for convenience.

Any personal recomendations?

Quote from: bennetng on 2022-08-13 13:28:56

Do you notice when you use foobar's converter to encode mp3, "Output bit depth" and "Dither" in the converter dialog are not available? When you click the "Edit" button then choose "Custom" in the drop down dialog, if you specify the format is "lossy", then foobar will treat the format as lossy, and the transcode waning will not show up. foobar of course has these presets out of the box so users don't need to manually do this, unless you are using other unpopular encoders.

As mentioned, foo_openmpt54 may render some files with >0dBFS values, so it is not only a matter of "resolution", but also compatibility. Without paying attention, casual conversion to FLAC may induce clipping, so the warning makes perfect sense: users should take care of audio level themselves.

That's the problem - MODs have no bit depth. Look at MP3 Properties how fb2k handles them - there's no bit depth. The same should be with MODs.
Just like with MP3 you rather handle >0dBFS with ReplayGain/DSP when transcoding, not bit depth of target format.

Quote

I'd say in terms of transparency, there is no need to convert any audio format, including generic ones like DSD and Hi-res PCM beyond 16/44 if the differences cannot be ABX'ed. The whole thing has nothing to do with MOD music at all.

We're talking about sane defaults - by default MODs should be quietly converted to 16bits so beginners like OP don't do insane things with converting them to 32bit lossless. If one has special needs of course the choice shall remain.

Quote

You are limiting yourself to the so-called "legacy" impression of "MOD" music to some specific old hardware or software, just some examples of demos require a fairly modern computer to run utilizing tracker music:
https://www.pouet.net/

Even the foobar plugin being discussed (OpenMPT) is orginated from a modern PC tracker, see the advanced features:
https://openmpt.org/features

You're talking to a guy whose tracker music was used in some games, believe me Pouet and OpenMPT are no news to me :]
No MOD in existence has samples over 16bits, no MOD in existence has been mastered for anything higher than 16bits. Yes some newer trackers may be using DSP or synth with precision higher than that, or floating point, just like MP3 internally is floating point. It doesn't change the fact that at the end you don't decode MODs or MP3 to anything higher than 16bits, unless for some special purposes. Period.

Thanks for explaining. This topic is quite deeper than I though.

Also what should I do with these settings when converting so many different file types? Thanks a lot to all for the discussion as I'm learing more about it.

Enable Decode Postprocessing (Disabled)
Don't Reset DSP between Tracks (Disabled)
Output Bit Depth (Auto)
Dither (never)

Thanks, I started testing, and will get back to you, I tried to convert the files to .wv but the file size was huge for some reason uknown to me. I did set up the "slider" to the smallest compression mode "Extra High", and additional processing 4 to see what was the results. For some reason I'm getting huge files around 50-100 mb per file lol. Here is a pic of what it shows.

What can you recommend? Should I do another conversion from .wv to another file format? My goal is to have a file size no more than 20-30 mb per file and have those files in a popular format that can accept tags, and when converted not being significatly distored from the original file or have encoding problems due to the technical aspects that I'm not probably aware about.

The files are big because kode54, the (already retired) author of the plugin used 96kHz as the plugin's default output sample rate, and if you are rendering to 32-bit (float) WavPack, the files will also be bigger.

While it is possible to set the sample rate within the plugin, without knowing what and how the plugin is exactly doing and without trying every tracker format, a safer (audibly transparent when compared to the plugin's default settings) way to reduce sample rate is to insert a resampler in the file converter's DSP chain. foobar's built-in RetroArch resampler is a decent choice, of course there are other popular choices like the SoX-based plugin:
https://hydrogenaud.io/index.php?topic=67376.0

I mentioned this because for example, foo_midi, another plugin with a similar nature, also has a sample rate setting within the plugin, and setting the sample rate within the plugin can have a different meaning from using a resampler outside of the plugin, as mentioned here:
http://www.un4seen.com/forum/?topic=13919.0

It is also possible to reduce the output to 16-bit, but without knowing the tracker files' rendered volume level, there is a risk of clipping, or in other cases, the volume could be too low. To avoid this when doing batch conversion, you can firstly use a fast lossless WavPack settings and render to 32-bit with an external DSP resampler set to 44.1kHz, then use the rendered WavPack files as an intermediate format to insert ReplayGain data, and finally, convert the intermediate WavPack files to ReplayGain-adjusted 16-bit WavPack (or FLAC) with slower settings. I tried to insert ReplayGain data into a tracker file and got an error that the format is unsupported, therefore intermediate WavPack files are necessary for this operation.

I would leave the ReplayGain tutorial to Porcus, the explanations could be quite lengthy for first time users.

Quote from: rutra80 on 2022-08-13 13:18:47

Really? You should get the warning while transcoding internally float32 MP3 to FLAC?  :))
You don't downconvert anything from MOD to FLAC the same as you don't downconvert anything from MP3 to FLAC.

Yes, I totally agree and understand that from MP3 and FLAC, but both are popular and can be played with normal players, but the original sound file for example  669, AHX, AMF, DMF, DSM, FAR, HVL, IT, MDL, MED, MO3, MOD, MPTM, MTM, PLM, S3M, STM, ULT, XM are not and I want to be able to play them with a phone in something more of a popular format, and for that I need to convert them. I can lose a bit of quality, but if I do so then so be in a way that not significant, that's why I want the conversion process to be free of artifacts,  sound errors, or even conversion errors. But also I want to be able to get tags embeded into the file for convenience.

Any personal recomendations?

Nonono! I know this topic got confusing, but above I didn't mean that you shouldn't convert MOD to FLAC! It was my answer to Porcus meaning that such conversions aren't necessarily lossy! Please ignore it.

Your case is very simple:
I would convert to MP3 (or whichever lossy format is convenient for you, AAC, Opus, etc.) because on PC you don't hear most of the modules perfectly as in original anyway.
If you hear annoying compression artifacts (which is not so uncommon with such artificial music), go with FLAC. In that case I would convert to 32kHz 16bit FLAC, you can go with universally compatible 44,1kHz 16bit FLAC.
In your case there's no point in anything else really.

I would install the External Tags component, configure it, make external tags and keep the originals - and then for portable use I would go for something lossy.

An idea I have employed is to use a "rare" lossy for disposable files. E.g. Musepack. Or Opus.
An m4a might not be a "disposable copy" here, because I have many files downloaded as m4a, and if I make a total mess out of everything, then I might have to spend time cleaning up - but if I see a Musepack file, I know where it came from.

I would install the External Tags component, configure it, make external tags and keep the originals - and then for portable use I would go for something lossy.

An idea I have employed is to use a "rare" lossy for disposable files. E.g. Musepack. Or Opus.
An m4a might not be a "disposable copy" here, because I have many files downloaded as m4a, and if I make a total mess out of everything, then I might have to spend time cleaning up - but if I see a Musepack file, I know where it came from.

Ok, regarding the volume differences in the tracks?

Scan originals for replaygain and apply it when converting.

Quote from: arepakiller on 2022-08-13 19:10:30

Thanks, I started testing, and will get back to you, I tried to convert the files to .wv but the file size was huge for some reason uknown to me. I did set up the "slider" to the smallest compression mode "Extra High", and additional processing 4 to see what was the results. For some reason I'm getting huge files around 50-100 mb per file lol. Here is a pic of what it shows.

What can you recommend? Should I do another conversion from .wv to another file format? My goal is to have a file size no more than 20-30 mb per file and have those files in a popular format that can accept tags, and when converted not being significatly distored from the original file or have encoding problems due to the technical aspects that I'm not probably aware about.

The files are big because kode54, the (already retired) author of the plugin used 96kHz as the plugin's default output sample rate, and if you are rendering to 32-bit (float) WavPack, the files will also be bigger.

While it is possible to set the sample rate within the plugin, without knowing what and how the plugin is exactly doing and without trying every tracker format, a safer (audibly transparent when compared to the plugin's default settings) way to reduce sample rate is to insert a resampler in the file converter's DSP chain. foobar's built-in RetroArch resampler is a decent choice, of course there are other popular choices like the SoX-based plugin:
https://hydrogenaud.io/index.php?topic=67376.0

I mentioned this because for example, foo_midi, another plugin with a similar nature, also has a sample rate setting within the plugin, and setting the sample rate within the plugin can have a different meaning from using a resampler outside of the plugin, as mentioned here:
http://www.un4seen.com/forum/?topic=13919.0

It is also possible to reduce the output to 16-bit, but without knowing the tracker files' rendered volume level, there is a risk of clipping, or in other cases, the volume could be too low. To avoid this when doing batch conversion, you can firstly use a fast lossless WavPack settings and render to 32-bit with an external DSP resampler set to 44.1kHz, then use the rendered WavPack files as an intermediate format to insert ReplayGain data, and finally, convert the intermediate WavPack files to ReplayGain-adjusted 16-bit WavPack (or FLAC) with slower settings. I tried to insert ReplayGain data into a tracker file and got an error that the format is unsupported, therefore intermediate WavPack files are necessary for this operation.

I would leave the ReplayGain tutorial to Porcus, the explanations could be quite lengthy for first time users.

So in this case:

Convert Tracker Files to WavPack with fast encoding settings with Additional decoding (Enable Decode Possprocessing) and Resampler (RetroArch)?

Scan Files with ReplayGain and add ReplayGain Tags to Files.

On this last step "ReplayGain-adjusted 16-bit WavPack (or FLAC) with slower settings" do you mean  to Convert the WavPack files to FLAC with 16-Bit Output, No extra processing, and Transfer Tags (including ReplainGain Metadata)? Or How do I convert the WavFiles to ReplayGain-adjusted 16 Bit?

Also, is WavPack better and encoding than FLAC, not accounting for speed?

If you convert to lossy, it is enough to RG scan target files (and then eventually apply RG to file content if your target app doesn't support RG).

If you convert to FLAC, install External Tags component so you can scan original modules and skip intermediate WavPack conversion. Then in Converter set output bit depth to 16-bit, processing to apply track gain and prevent clipping according to peak, and activate Resampler DSP with 32 or 44,1kHz target sample rate.

WavPack files are usually smaller than FLAC.

The reason I suggested WavPack was that it is the only well-supported codec that can accommodate floating-point (32-bits) - that is clipping free and you won't have to worry about applying ReplayGain (indeed, you can RG scan afterwards).
If you peak-normalize to store as 16-bit integer, you can use pretty much any codec you like. And yes, using External Tags you get RG tags to the module files without going by way of WavPack.

As for how WavPack compresses ... for music, the typical order of sizes is ALAC larger than FLAC larger than WavPack larger than TAK/Monkey's larger than OptimFROG, but for chiptune signals one might be in for surprises, so if you are concerned about size ...
Try then WavPack settings -hx4 or -hhx4 and see if they improve over default.  WavPack "fast" does not compress very well, but wavpack.exe can recompress WavPack files in-place, using drag and drop with renaming for custom options (https://wiki.hydrogenaud.io/index.php?title=WavPack#Drag_and_drop_.28Windows.29), so you can use the WavPack -f (for speed) until you are sure your settings work.