1
Compos / Re: OpenMPT FM+PCM example song compo (preliminary deadline 2018-09-30)
« Last post by LPChip on September 18, 2018, 18:28:48 »Only a few more weeks before the deadline ends...
Recent Posts
2
Free Music Downloads / Re: [Trance+Techno+Rock] Fearless
« Last post by monsterovich on September 18, 2018, 00:01:41 »Quote
I think there are some questionable harmonies early on (around 0:15-0:20) though.
Which one of the instruments exactly do you mean?
If you mean horn, perhaps, a bit. But I didn't notice anything after listening this part over 200 times in my headphones and speakers... or it's just me?
3
Free Music Downloads / Re: [Trance+Techno+Rock] Fearless
« Last post by Saga Musix on September 17, 2018, 18:54:24 »Nice combination of styles (could probably fit into the EBM genre to some degree rather than Rock). I think there are some questionable harmonies early on (around 0:15-0:20) though.
4
Free Music Downloads / [Trance+Techno+Rock] Fearless
« Last post by monsterovich on September 15, 2018, 10:01:38 »I'm not sure about genre.
Soundcloud: https://soundcloud.com/monsterovich/fearless
You may also support me in my work by buying my track in flac if it deserves that.
Bandcamp: https://monsterovich.bandcamp.com/track/fearless
Fun facts:
Original mptm file is 17,5 mb.
All instruments are multi-sample except drums, snares and effects.
VST plugins were used over 30 times. https://imgur.com/a/PEO6dhW
Soundcloud: https://soundcloud.com/monsterovich/fearless
You may also support me in my work by buying my track in flac if it deserves that.
Bandcamp: https://monsterovich.bandcamp.com/track/fearless
Fun facts:
Original mptm file is 17,5 mb.
All instruments are multi-sample except drums, snares and effects.
VST plugins were used over 30 times. https://imgur.com/a/PEO6dhW
5
General Chatter / Re: Huge MP3 samples (was: Apple Music)
« Last post by Wodd on September 10, 2018, 19:50:19 »Plugins are another thing that I hadn't considered, as I do not use them. The vendor for that file has a shorter version of the same audio. That worked with no problems.
6
General Chatter / Re: Huge MP3 samples (was: Apple Music)
« Last post by manx on September 10, 2018, 15:07:10 »Neither file did load anything near properly, both before and after my changes for me.
The required result is that they do not load, because samples that long are unsupported.
The precise amount of length a sample will be able to use is unknown upfront, which is why the arbitrary limit is lower than the theoretical maximum.
This depends on address space layout randomization, amount of memory occupied by things already loaded in OpenMPT, installed shell plugins (which run in every process using file selection dialogs), address space fragmentation, the way the standard library implements growing of the temporary std::vector memory buffer, and various other things. Also, OpenMPT maps all input files into its address space, which further reduces the amount of available address space by, in this case, 600MB.
Also, even in 64bit OpenMPT neither file can load properly because sample length is stored as a 32bit value.
tl;dr: The limit is there for a reason, and it will not go away (either anytime soon, or possibly at all for 32bit OpenMPT). Changing the limit to 0x7fffffff will not fix anything or even make it possible to load larger samples at all on 32bit. It also makes no sense even for 64bit because, for various file formats, saving could not represent that sample length either.
OpenMPT is not designed to be used with multiple-hours long audio tracks, and it does not want to be that. There is better software out there than a tracker for such use cases.
The required result is that they do not load, because samples that long are unsupported.
The precise amount of length a sample will be able to use is unknown upfront, which is why the arbitrary limit is lower than the theoretical maximum.
This depends on address space layout randomization, amount of memory occupied by things already loaded in OpenMPT, installed shell plugins (which run in every process using file selection dialogs), address space fragmentation, the way the standard library implements growing of the temporary std::vector memory buffer, and various other things. Also, OpenMPT maps all input files into its address space, which further reduces the amount of available address space by, in this case, 600MB.
Also, even in 64bit OpenMPT neither file can load properly because sample length is stored as a 32bit value.
tl;dr: The limit is there for a reason, and it will not go away (either anytime soon, or possibly at all for 32bit OpenMPT). Changing the limit to 0x7fffffff will not fix anything or even make it possible to load larger samples at all on 32bit. It also makes no sense even for 64bit because, for various file formats, saving could not represent that sample length either.
OpenMPT is not designed to be used with multiple-hours long audio tracks, and it does not want to be that. There is better software out there than a tracker for such use cases.
7
General Chatter / Re: Huge MP3 samples (was: Apple Music)
« Last post by Wodd on September 10, 2018, 14:37:35 »Since I am not a moderator for the source code, I don’t any longer use the 32-bit build. I have been using the 64-bit build exclusively for a while now. Sadly, because my computer was recently reloaded, I do not have access to the code, as to attempt debugging why the file will not load. I did math for finding the approximate sample length of the file. Given that I did increase MAX_SAMPLE_LENGTH to 2,147,483,647 (as going beyond that did not work, even when the controlling integer was 64-bit), it should load at only approximately 1,587,601,191 samples. But, it does not. Even if accounting for doubling of the size for memory usage, that is still only 1.073 GiB (gibibytes) or 1.152 GB (gigabytes). I don’t mean to anger you, manx. But, I am confused as to why the campfire file will not load when the Counting and Primes file, which is larger in size and more than twice the length, opens with no problems.
8
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).
9
General Chatter / Re: Huge MP3 samples (was: Apple Music)
« Last post by Wodd on September 10, 2018, 09:36:01 »Quote from: manx
In 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.
10
General Chatter / Re: Huge MP3 samples
« Last post by manx on September 10, 2018, 08:59:19 »1. OpenMPT does not properly reject MP3 samples longer than MAX_SAMPLE_LENGTH.Fixed in r10760. Will be backported to 1.27 soon.
2. OpenMPT 64bit does not stop allocating memory after MAX_SAMPLE_LENGTH of data has already been decoded (this applies equally to MP3, Vorbis, Opus samples).Fixed in r10762. Will be backported to 1.27 soon.