Since one would to to control looping using the "smpl" chunk it makes no
sense for vgmstream to loop the song.
Also write "smpl" before "data" as it looks cooler
It's not the easiest thing to follow so here is what's going on with
STREAMFILEs:
- external player opens base-streamfile, with a base FILE
- meta scd parses stuff, then per DSP channel/layer:
- open temp-streamfile, which does custom IO with base-streamfile
(doesn't open any FILE)
- pass temp-streamfile to init_vgmstream_ngc_dsp_std
- init parses ok, and re-opens temp-streamfile (with custom IO) as its
own dsp-vgmstream-streamfile; internally it does fopen/fdopen the
original FILE from base-streamfile
- scd_int_layout stores the newly created VGMSTREAM (internally has
the dsp-vgmstream-streamfile too)
- close temp-streamfile, that doesn't close base-streamfile as it's
wrapped to avoid doing so, nor affects dsp-vgmstream-streamfile in any
way.
- meta parsing is done, so external player closes base-streamfile (but
the re-fopen'ed dsp-vgmstream-streamfile FILE remains)
- vgmstream renders pcm buffers, etc
- finally player calls close_vgmstream
- scd_int_layout calls close_vgmstream for each stored VGMSTREAM
- the VGMSTREAM internally closes the dsp-vgmstream-streamfile, which
in turn closes its own FILE
So ultimately all FILEs, STREAMFILEs and their clones should be properly
handled and closed.
Don't adjust loops to frame boundaries since offsets are always aligned
and MSF only does CBR. There was a minor bug getting samples: FFmpeg was
parsing the MSF and would add its header to the bitrate, which was used
for calcs. Now FFmpeg only sees the MP3 data.
Use mpg123 if available too since it's easier to setup in non-Windows
builds (no audible differences otherwise).
