SNDH tracks don't stop playing

[chris-y]

In the SNDH archive, file Daglish_Ben/Footballer_of_the_Year_2.sndh plays a couple of seconds then the rest is silent.
In interactive mode it shows that it is still playing track 1 although there is no sound.
Is it possible to get psgplay to move onto the next track when the first one has finished playing? --stop=auto isn't working for this particular file.
Maybe silence detection is required?

Originally mentioned in #13 (comment)

[frno7]

The TIME tag in the SNDH format is a provision for the length of a track in seconds:

psgplay/doc/sndhv21.txt

Lines 53 to 54 in d719a9b

	; TIME (sub) tune time dc.b 'TIME' None SNDHv2
	; (in seconds) dc.w x1,x2,x3,x4

Sadly, most SNDH files don’t have it. Most proper tracks, that aren’t sound effects, programmatically play for ever in a loop, and so silence is an unreliable means of track length determination. Many tracks that do have TIME have it at 0, meaning looping for ever anyway.

I’ve seen efforts to measure true SNDH track lengths. Maybe someone maintaining the SNDH archive could be convinced it would be worthwhile for an update? Best would be millisecond resolution, to avoid spurious bleeps and hisses at track endings!

The --info option displays all SNDH tags. Here’s one exceptional example having a TIME of 208 seconds:

% psgplay --info Mad_Max/Last_Ninja.sndh
path Mad_Max/Last_Ninja.sndh
tag field TITL Last Ninja
tag field COMM Mad Max
tag field RIPP Grazey / PHF
tag field CONV Grazey / PHF
tag field FLAG ~ y PSG
tag field TIME 1 208
header size 94
data size 10476

Since TIME is so rarely available, PSG play doesn’t really make good use of it, as of yet.

[benjihan]

Hi,

sc68 has a database for sndh track length. Lengths are automatically measured using mksc68 time command. I am supposed to update the whole sndh database someday with the duration and FLAG tag updated. Meanwhile the database is hardcoded here.
I can also provide the latest database to this day if you are interested. It looks something like that:

sndh YsaA -------------------------------- fffaeaae 01 03:27 00010362 00050 00-69bdfd3c19e36780eda12f7d18ac3f24 02477 - No More - leif Rullar conversion.sndh

--
Ben/OVR

[frno7]

TIMEDB_ENTRY( fffaeaae, 1, 10362, TB+TD+YM), /* 02477 - No More - leif Rullar conversion */

Hmm, the 10362 entry must be... half the resolution of a centisecond? Which is to say the count of 1/50 seconds, so the vertical blank timing of PAL? :-) Much better than full seconds.

I am supposed to update the whole sndh database someday with the duration and FLAG tag updated.

Nice! How are things proceeding?

[benjihan]

Hmm, the 10362 entry must be... half the resolution of a centisecond? Which is to say the count of 1/50 seconds, so the vertical blank timing of PAL? :-) Much better than full seconds.

The length is the number of frames to run. Hence the duration depends on this value and the replay rate. Like you said most of the time it's a 50hz PAL VBL per frame. A hash code is used to identify the (unpacked) file. The algorithm can be found in the file68.c::isread() function.

Nice! How are things proceeding?

Unfortunately I've been slacking on this for quiet sometime now. The thing is I have a completely rewritten version of sc68 in progress more like stalled right now.

I've just updated the timedb.inc.h file.

[frno7]

The length is the number of frames to run. Hence the duration depends on this value and the replay rate. Like you said most of the time it's a 50hz PAL VBL per frame.

Is it feasible to add a millisecond resolution (or there about) SNDH tag, that is simple to interpret as track length, for SNDH players?

Unfortunately I've been slacking on this for quiet sometime now. The thing is I have a completely rewritten version of sc68 in progress more like stalled right now.

Oh, how did the desire to rewrite sc68 come about?

I've just updated the timedb.inc.h file.

TIMEDB_ENTRY( 503196f8,  1,        84,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  2,       132,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  3,       517,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  4,        64,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  5,        27,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  6,        56,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  7,        42,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  8,        42,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8,  9,        82,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8, 10,        67,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */
TIMEDB_ENTRY( 503196f8, 11,      4952,      YM), /* 00851 - Ben Daglish - Footballer of the Year 2 */

As suspected, only track 11 is anywhere near a length of a proper tune. :-)

[benjihan]

Is it feasible to add a millisecond resolution (or there about) SNDH tag, that is simple to interpret as track length, for SNDH players?

It's certainly possible. I don't think Grazey or Evil would mind.The number of frames is the most accurate you can get. sc68 files store the first run length and the loop length (0=non looping). I understand having to do mul/div on somewhat big numbers can be an hassle in 68k/asm ms = (uint64_t) frames * 1000 / replay_rate. May be a { uint8_t h, m, s, centi ) or a bcd coded $HMMSSMSE.
IIRC the current sndh TIME tag can not be used for multiple song files.

Oh, how did the desire to rewrite sc68 come about?

Mainly the STe DMA/LMC simulation really needed work. I was not happy with the m68k simulator compiled code being huge because of generated code. That was fast at the time but useless nowaday. The project need an overall cleaning.

As suspected, only track 11 is anywhere near a length of a proper tune. :-)

Indeed. One thing I wanted to add with the FLAG tag is a JINGLE flag and a SFX flag. Duration works fairly well as a proxy.

[frno7]

IIRC the current sndh TIME tag can not be used for multiple song files.

Mad_Max/Games/SID/Warp.sndh has a TIME for every track it has, no?

% psgplay --info Mad_Max/Games/SID/Warp.sndh
path Mad_Max/Games/SID/Warp.sndh
tag field TITL Warp - Sid
tag field COMM Mad Max
tag field RIPP Grazey / PHF
tag field CONV Grazey / PHF
tag field YEAR 2017
tag field ## 8
tag field !# 1
tag field !V 50
tag field TIME 1 219
tag field TIME 2 80
tag field TIME 3 70
tag field TIME 4 95
tag field TIME 5 148
tag field TIME 6 20
tag field TIME 7 6
tag field TIME 8 93
header size 126
data size 12388

[benjihan]

Mad_Max/Games/SID/Warp.sndh has a TIME for every track it has, no?

Right. I was not sure about that. I remember now TIME argument is an array of word. I thought it was stored as a string I was confusing it with ##

[frno7]

@chris-y, with commit e6da8e7, the length, if available as a tag in the SNDH, is indicated next to each track. It doesn’t proceed to the next track automatically, yet, but it seems to be a good idea to have it do that. Example:

PSG play                           01:23
Mad Max
Warp - Sid

> 1. Warp - Sid                    03:39
  2. Warp - Sid                    01:20
  3. Warp - Sid                    01:10
  4. Warp - Sid                    01:35
  5. Warp - Sid                    02:28
  6. Warp - Sid                    00:20
  7. Warp - Sid                    00:06
  8. Warp - Sid                    01:33

[chris-y]

On the command line it should stop at the correct time too?

[frno7]

Should command mode stop and quit after a track, whereas interactive mode proceeds to the subsequent track? After all, as a command it can easily be scripted, to do other things.

[chris-y]

Yes, I would suggest so. I suppose it could be an option to play through.
Maybe if a track is specified, it stops after playing, and if not it starts at track 1 and plays through them all?

[frno7]

The SNDH format has a default track

psgplay/doc/sndhv21.txt

Line 47 in e6da8e7

; !#?? Default Sub tune dc.b '!#02',0 0 (Null) SNDHv21

and so, unless a track is specified, the command may as well play the last track, if it happens to be the default. Of course, the command could still run through them all, if it plays track 1 after the last track, and then stops at the track preceding the default track. Someone will have to write a good user’s manual for this, I fear... :-)

[frno7]

There’s also a slight complication in the fact that tracks may be expressly endless

psgplay/doc/sndhv21.txt

Lines 118 to 119 in e6da8e7

	; tunes). Each word contains the length of each sub tune in seconds. If the
	; word is null then it is assumed that the tune endlessly loops.

meaning it won’t stop, quit or proceed automatically. Perhaps a --length-default=<[mm:]ss[.ss]> option could terminate tracks that are either indeterminate or expressly endless. Tracks that do have finite lengths would still play to completion, regardless.

[chris-y]

Shouldn't --length=xxxx do this already?

[frno7]

Shouldn't --length=xxxx do this already?

The --length option overrides lengths for tracks that do have finite lengths, meaning that if SNDH specifies that a certain track is, say, 3 minutes, --length=02:00 would stop it after 2 minutes. The --length-default option would only override tracks that don’t have a length specified by SNDH or are expressly endless.