Recent Posts91
General Chatter / Re: Huge MP3 samples (was: Apple Music)
« Last post by manx on September 10, 2018, 10:38:46 »Quote from: manxIn any case, OpenMPT will probably never support samples as long or big as this example.Length is not the issue. To verify, change the MAX_SAMPLE_LENGTH to at least 7fffffff (2,147,483,647) and load Counting and Primes into the newly built mptrack.exe. (Use 64-bit) After that file loads, try again to load the campfire file. You should notice that Counting and Primes loads with no problems; but, the campfire file still fails to load, yielding the Unknown File Format dialog. I tested Windows Media Player, Groove Music, and a third player and all of them load the campfire file with no problems. But, OpenMPT will not properly read it. I looked at the sizes of Counting and Primes and the campfire file and Counting and Primes is larger in size, but loads into OpenMPT with no problems. Size is not an issue here.
Length is the issue. OpenMPT cannot represent samples as long as either of the examples you have given. The only sane option is to reject those files, as the user would otherwise expect the complete file getting loaded when in fact in would absolutely NEED to be truncated to some arbitrary length.
The arbitrary length chosen by OpenMPT is MAX_SAMPLE_LENGTH. Increasing the length will not change anything about that fact (both examples still will not fit).
7fffffff makes no sense as a limit because samples that long can
1. not be loaded into a 32bit OpenMPT on 32bit host systems *at all* (not enough user virtual address space available on x86 Windows)
2. not be stored in any module format supported by OpenMPT (all of them are basically limited to 32bit for the whole module file due to width of on disk structure fields.
OpenMPT therefore limits MAX_SAMPLE_LENGTH to 0x10000000, which, for stereo/16bit, amounts to 1GB of data (which can still be handled by file formats and the limited amount of virtual address space available on 32bit x86 Windows).