I have Lua code that (slowly) loads a mono 44100Hz 16-bit wave file into a table which could be split up and written to separate wave files.
However, doing it by "markers" requires being able to read chunks in the wave file. The loop point of a WAV sample is a separate chunk.
I haven't been able to completely master the ability of reading chunks beyond the "data" chunk. Also keep in mind that programs like Audacity like to save the chunk with "marker" listing before the "data" chunk. In addition, Wavosaur saves its own "saur" chunk to be able to recall a volume envelope without having to save another file that could be easily lost.
The second chunk of the file could usually be discovered after the first 40 bytes of the WAV file. The first one is "fmt " (with space as fourth character) which describes the attributes such as sampling rate, bit rate and compression technique. Compressed WAV files are a pain, need to be able to work with a codec for that. With stereo files, the difference from mono files is that the data is interlaced, ie. left side, then right side, then left side, then right side etc. I haven't looked at a WAV which has more than two channels but it should be alike, but few programs support such a thing even for 5.1 Surround sound. Dealing with 32-bit float WAV is another monster but might be necessary today, as many digital audio workstations support it.
For a QB64 program, sadly have to read the WAV file twice. Once with the programming system's means to get the sample data, and again separately in the old-fashioned way in order to go hunting for those chunks. It might be easier than expected to interpret the sample frames, taken directly from "marker" information, so that the programmer knows where in the sample data buffer to start or finish copying from.
I had to read the first post again. If it has nothing to do with "markers" already in a wave file then this should be even easier. Find the way to convert a time like 4:50 into sample frame value. IINM it should be 22050 for one second of 44100Hz sampling rate, regardless of bit rate because QB64(PE) has code to convert from a different sampling rate and perhaps from a different bit rate as well. This sample frame number is invariably needed for using with _MEMCOPY, to copy from the big WAV file into a new buffer obviously created with another _MEM variable. Could steal the WAV file header for output file but have to fill in the size of the wave file at byte position 5, and the size of the "data" chunk at the position just after that word as it appears.
EDIT: If you don't need to do this in a QB64 program, and if audiophile sound quality isn't important, convert WAV to OGG Vorbis and then use "vcut" to split:
https://github.com/xiph/vorbis-tools
This is what I recommend, although there are different tools for MP3 and maybe for FLAC.
However, doing it by "markers" requires being able to read chunks in the wave file. The loop point of a WAV sample is a separate chunk.
I haven't been able to completely master the ability of reading chunks beyond the "data" chunk. Also keep in mind that programs like Audacity like to save the chunk with "marker" listing before the "data" chunk. In addition, Wavosaur saves its own "saur" chunk to be able to recall a volume envelope without having to save another file that could be easily lost.
The second chunk of the file could usually be discovered after the first 40 bytes of the WAV file. The first one is "fmt " (with space as fourth character) which describes the attributes such as sampling rate, bit rate and compression technique. Compressed WAV files are a pain, need to be able to work with a codec for that. With stereo files, the difference from mono files is that the data is interlaced, ie. left side, then right side, then left side, then right side etc. I haven't looked at a WAV which has more than two channels but it should be alike, but few programs support such a thing even for 5.1 Surround sound. Dealing with 32-bit float WAV is another monster but might be necessary today, as many digital audio workstations support it.
For a QB64 program, sadly have to read the WAV file twice. Once with the programming system's means to get the sample data, and again separately in the old-fashioned way in order to go hunting for those chunks. It might be easier than expected to interpret the sample frames, taken directly from "marker" information, so that the programmer knows where in the sample data buffer to start or finish copying from.
I had to read the first post again. If it has nothing to do with "markers" already in a wave file then this should be even easier. Find the way to convert a time like 4:50 into sample frame value. IINM it should be 22050 for one second of 44100Hz sampling rate, regardless of bit rate because QB64(PE) has code to convert from a different sampling rate and perhaps from a different bit rate as well. This sample frame number is invariably needed for using with _MEMCOPY, to copy from the big WAV file into a new buffer obviously created with another _MEM variable. Could steal the WAV file header for output file but have to fill in the size of the wave file at byte position 5, and the size of the "data" chunk at the position just after that word as it appears.
EDIT: If you don't need to do this in a QB64 program, and if audiophile sound quality isn't important, convert WAV to OGG Vorbis and then use "vcut" to split:
https://github.com/xiph/vorbis-tools
This is what I recommend, although there are different tools for MP3 and maybe for FLAC.