issue with SNDH v2.2 files with sub tunes

[dnalor]

when using psgplay built from the latest code, trying to convert a SNDH V2.2 file with >1 sub tunes results in this error:

psgplay -o /dev/stdout --stop=auto --mode=command --psg-mix=linear "Dma-Sc/ADN_Quiz.sndh"|sox --multi-threaded --norm=-3 -q -V0 --ignore-length -t wav - -t flac - > /tmp/XX.flac
psgplay: error: Dma-Sc/ADN_Quiz.sndh: unrecognised data in 75 bytes at offset 119
psgplay: error: /dev/stdout: WAVE opened for writing without duration

system info:

Linux 6.12.23-gentoo #1 SMP PREEMPT_DYNAMIC Tue Apr 15 11:29:26 CEST 2025 x86_64 AMD Ryzen 5

file tag info:

subtunes frames: [6239,4095,1427,3215,3263,1679,6143,2815,2943,5543,6271,6239,8191,3635,6143]
tag=\{'COMMENT' => 'Ripper: N/A | Converter: Grazey | Timer: 20Hz | Sub Tunes: 15 | Frames: 67841','SIZE' => '203942','ARTIST' => 'DMA-SC','YEAR' => '2025','TITLE' => 'ADM Quiz','ALBUM' => 'Dma-Sc','STEREO' => 2,'SECS' => 3392}

The file is from the SNDH updates from January . I've tried some others with multiple sub tunes from there with the same results. Files with one sub tune work fine.

Any ideas would be appreciated.

[frno7]

file tag info:

subtunes frames: [6239,4095,1427,3215,3263,1679,6143,2815,2943,5543,6271,6239,8191,3635,6143]
tag=\{'COMMENT' => 'Ripper: N/A | Converter: Grazey | Timer: 20Hz | Sub Tunes: 15 | Frames: 67841','SIZE' => '203942','ARTIST' => 'DMA-SC','YEAR' => '2025','TITLE' => 'ADM Quiz','ALBUM' => 'Dma-Sc','STEREO' => 2,'SECS' => 3392}

Your file info seems to completely ignore that the SNDH header actually has a FLAG field as well? It isn’t printed in your output?

Indeed, it looks like a problem with the FLAG field in the header. I don’t know exactly what they’ve done with the FLAG field in the v2.2 format, but a ~ character following FLAG is missing in your SNDH file? I believe FLAG without ~ was somewhat undocumented, with distinct flags per subtune, but in your case it doesn’t seem quite correct either. Disassembly:

% psgplay --disassemble --disassemble-header ADN_Quiz.sndh | head -n24
psgplay: error: /tmp/ADN_Quiz.sndh: unrecognised data in 75 bytes at offset 119
init:
	bra.w	_init				; init
exit:
	bra.w	_exit				; exit
play:
	bra.w	_play				; play
sndh:
	dc.b	$53,$4e,$44,$48,$54,$49,$54,$4c	; SNDHTITL
	dc.b	$41,$44,$4d,$20,$51,$75,$69,$7a	; ADM Quiz
	dc.b	$00,$43,$4f,$4d,$4d,$44,$4d,$41	; .COMMDMA
	dc.b	$2d,$53,$43,$00,$52,$49,$50,$50	; -SC.RIPP
	dc.b	$4e,$2f,$41,$00,$43,$4f,$4e,$56	; N/A.CONV
	dc.b	$47,$72,$61,$7a,$65,$79,$00,$59	; Grazey.Y
	dc.b	$45,$41,$52,$32,$30,$32,$35,$00	; EAR2025.
	dc.b	$23,$23,$31,$35,$00,$54,$43,$32	; ##15.TC2
	dc.b	$30,$30,$00,$00,$46,$4c,$41,$47	; 00..FLAG
	dc.b	$00,$22,$00,$22,$00,$22,$00,$22	; ."."."."
	dc.b	$00,$22,$00,$22,$00,$27,$00,$22	; .".".'."
	dc.b	$00,$27,$00,$22,$00,$22,$00,$22	; .'."."."
	dc.b	$00,$22,$00,$22,$00,$22,$61,$62	; ."."."ab
	dc.b	$64,$79,$00                    	; dy.
_sndh:
	dc.b	$61,$64,$79,$00,$00,$46,$52,$4d
	dc.b	$53,$00,$00,$18,$5f,$00,$00,$0f

The command find -iname '*.snd*' -type f -print0 | xargs -0n1 psgplay -i >sndh.tags 2>sndh.errors on all SNDH files in the archive shows the following errors:

% cat sndh.errors
psgplay: error: ./Mad_Max/Games/SID/Masterblazer.sndh: unrecognised data in 63 bytes at offset 123
psgplay: error: ./Xfalcon/Randomazer.sndh: unrecognised data in 58 bytes at offset 120
psgplay: error: ./Piscol_Jurgen/Hard_n_Heavy.sndh: unrecognised data in 31 bytes at offset 109
psgplay: error: ./Piscol_Jurgen/X_Out.sndh: unrecognised data in 54 bytes at offset 114
psgplay: error: ./Ricky_Martin/Yoomp!.sndh: unrecognised data in 36 bytes at offset 110
psgplay: error: ./607/Lanatae.sndh: unrecognised data in 44 bytes at offset 104
psgplay: error: ./AD/ADN_Quiz.sndh: unrecognised data in 51 bytes at offset 107
psgplay: error: ./AD/DMA/ADN_Quiz.sndh: unrecognised data in 117 bytes at offset 111
psgplay: error: ./Dma-Sc/Nano_Cave.sndh: unrecognised data in 48 bytes at offset 112
psgplay: error: ./Dma-Sc/ADN_Quiz.sndh: unrecognised data in 75 bytes at offset 119
psgplay: error: ./Dma-Sc/Athanor_2.sndh: unrecognised data in 119 bytes at offset 145
psgplay: error: ./Dma-Sc/Quartet_Deluxe.sndh: unrecognised data in 36 bytes at offset 110
psgplay: error: ./Dma-Sc/Kolmik.sndh: unrecognised data in 375 bytes at offset 109
psgplay: error: ./Weichselbaum_Markus/Curse_of_Ra.sndh: unrecognised data in 66 bytes at offset 116
psgplay: warning: ./Nexus_6/Ofta_ma_wat_neues.sndh: tag TITL malformed whitespace
psgplay: warning: ./Syntheticgoddess/Flurry.sndh: tag !#SN malformed whitespace

Looks like 14 files in the SNDH archive have broken headers, where ADN_Quiz.sndh is one of them? Maybe @grazey can explain why the ~ for the FLAG field isn’t there as expected?

[frno7]

@dnalor, psgplay: error: /dev/stdout: WAVE opened for writing without duration says that the duration couldn’t be determined (presumably due to a broken FLAG field in the SNDH header). Hence, your option --stop=auto won’t work. However, if you supply an appropriate --length=<[mm:]ss[.ss]> it should work, while we’re waiting for the FLAG field to be updated with a fix in the SNDH archive? (Along with fixing the SNDH headers for 13 or so other broken files.)

[dnalor]

Thank you for the quick response.

Your file info seems to completely ignore that the SNDH header actually has a FLAG field as well? It isn’t printed in your output?

sorry, should have been clearer - these are just the tags I'm using (to integrate SNDH playback into an audio server), not all of them.

psgplay: error: /dev/stdout: WAVE opened for writing without duration says that the duration couldn’t be determined (presumably due to a broken FLAG field in the SNDH header).

It does seem I was mistaken to assume it was related to sub tunes.
That being said, both my server plugin (which supplies metadata to the server), and a CLI sndh2wav converter I've written as a workaround (using the Atari Audio Library) ignore the FLAG field and can determine the audio length (my understanding is that it's number of frames / timer frequency on second thought, I have to check this again ).
Maybe psgplay could just ignore the error in such a situation and play the file anyway?

if you supply an appropriate --length=<[mm:]ss[.ss]> it should work

That's a good idea - since the server gets the track length from my plugin, it could pass it as an argument to psgplay. As I mentioned above, for the time being I've switched to sndh2wav, but psgplay of course has a couple of nice features, so I'll look into this.

[frno7]

Maybe psgplay could just ignore the error in such a situation and play the file anyway?

It kind-of does that already: when PSG play encounters a malformed SNDH header, it stops parsing the rest of the header, because there’s no reliable way of coming back on-track for the rest of the SNDH header. But the header fields that have been parsed so far are still usable by PSG play. The problem in your case is that the FRMS field comes after the malformed FLAG field, so PSG play is unable to determine subtune durations in that particular case.

Some SNDH parsers might attempt to plow through whatever garbage data they find in headers (FLAG fields or otherwise), as opposed to stop and emit a parsing error as PSG play does. Out of the 5897 SNDH files in the archive, 14 appears to have malformed SNDH headers. I think the best course of action is to repair these file headers.

That's a good idea - since the server gets the track length from my plugin, it could pass it as an argument to psgplay. As I mentioned above, for the time being I've switched to sndh2wav, but psgplay of course has a couple of nice features, so I'll look into this.

Normally, for a perfectly valid SNDH file, neither --stop=auto nor --length are necessary, because PSG play can parse the FRMS field and automatically determine subtune durations. The --info option to PSG play displays the header fields it parses successfully.

[frno7]

@dnalor, by the way, I’m collecting feedback on whether to tag commit 0be9598 v0.8. What’s your take, is it good enough for the tag? :-)

[dnalor]

I think the best course of action is to repair these file headers.

I agree. I'll close this issue as soon as we've finished our discussion.

Normally, for a perfectly valid SNDH file, neither --stop=auto nor --length are necessary, because PSG play can parse the FRMS field and automatically determine subtune durations.

For some reason I added this, probably because I had some hanging conversion processes - unfortunately, this was a month ago, and I can't remember the exact circumstances - it may well have been due to the damaged files.

[dnalor]

by the way, I’m collecting feedback on whether to tag commit 0be9598 v0.8. What’s your take, is it good enough for the tag? :-)

I started with v0.7, and IIRC this didn't support the V2.2 specs, to I switched to -git. IMHO this is reason enough to release a new version, otherwise those starting with SNDH music may just assume psgplay doesn't work at all.
Apart from that, I've only used the non-interactive wav conversion, which generally seems to work well.
However, I haven't used psgplay that much, since I switched to sndh2wav for two reasons:

• I wanted to convert all sub tunes sequentially with one call
• psgplay is too slow on my server (Linux hp-t630 6.12.68-gentoo / x86_64 AMD GX-420GI)

Example:

$  time psgplay -o /tmp/ME_P.wav --mode=command  /data/music/VA\ -\ SNDH\ Music01/Modmate/Middle-Earth_Deconstructed.sndh
real    0m39.371s
user    0m38.804s
sys     0m0.210s

$  time sndh2wav  /data/music/VA\ -\ SNDH\ Music01/Modmate/Middle-Earth_Deconstructed.sndh /tmp/ME_S.wav
real    0m8.228s
user    0m7.982s
sys     0m0.175s

This is a problem, since the audio server I'm using only starts converting the next track ~70 sec before the end of the current one. As I can't change this, I'm currently writing a queuing / caching / parallel execution mechanism, but until this works, I can't really use psgplay.

[frno7]

I started with v0.7, and IIRC this didn't support the V2.2 specs, to I switched to -git. IMHO this is reason enough to release a new version, otherwise those starting with SNDH music may just assume psgplay doesn't work at all. Apart from that, I've only used the non-interactive wav conversion, which generally seems to work well.

Great! I’ve pushed the v0.8 tag now, and updated the Gentoo media-sound/psgplay package with a 0.8 ebuild.

* psgplay is too slow on my server (Linux hp-t630 6.12.68-gentoo / x86_64 AMD  GX-420GI)

Example:

$  time psgplay -o /tmp/ME_P.wav --mode=command  /data/music/VA\ -\ SNDH\ Music01/Modmate/Middle-Earth_Deconstructed.sndh
real    0m39.371s
user    0m38.804s
sys     0m0.210s

Very interesting. Middle-Earth_Deconstructed.sndh appears to have a duration of 422 seconds, and you’re saving it as a WAVE file in 39 seconds, which implies that playing it in real-time uses less than 10 % CPU? How come it’s too slow to play? PSG play has been playing on an iPad Air (1st generation, 2013), various Raspberry Pi (including Pi 3 Model A+), etc. Have you tried to increase the size of your ALSA buffers, to manage spikes in CPU demand and Linux kernel process scheduling issues?

The name of your device hp-t630 appears to be a 36" large format plotter? I’ve never heard PSG play run on something like a printer device before. :-)

$  time sndh2wav  /data/music/VA\ -\ SNDH\ Music01/Modmate/Middle-Earth_Deconstructed.sndh /tmp/ME_S.wav
real    0m8.228s
user    0m7.982s
sys     0m0.175s

This is a problem, since the audio server I'm using only starts converting the next track ~70 sec before the end of the current one. As I can't change this, I'm currently writing a queuing / caching / parallel execution mechanism, but until this works, I can't really use psgplay.

Configuring sufficiently large ALSA buffers seems much simpler to me, to the same effect, no?

[frno7]

@dnalor, related to the ALSA buffer discussion above, I’ve added a section on how to improve performance to README.md. It also mentions the nice command, which can be somewhat effective as well.

[dnalor]

Great! I’ve pushed the v0.8 tag now, and updated the Gentoo media-sound/psgplay package with a 0.8 ebuild.

Thanks, I'll switch to this one from -git
btw, I had some issues with psgplay-9999.ebuild: The shared lib failed to build (something about being unable to determine the version), so I changed it to static only:

46c46
<       emake DESTDIR="${D}" install-psgplay install-man || die
---
>       emake DESTDIR="${D}" install || die

which built successfully.

Very interesting. Middle-Earth_Deconstructed.sndh appears to have a duration of 422 seconds, and you’re saving it as a WAVE file in 39 seconds, which implies that playing it in real-time uses less than 10 % CPU? How come it’s too slow to play? PSG play has been playing on an iPad Air (1st generation, 2013), various Raspberry Pi (including Pi 3 Model A+), etc. Have you tried to increase the size of your ALSA buffers, to manage spikes in CPU demand and Linux kernel process scheduling issues?

As I noted above, I'm not using PSG play stand-alone, but as part of an integration of a number of video game/console/.. music formats (sndh, sid, uade, vgm, psf, ...) into an audio server. This consists of 2 parts:

• a server plugin to supply metadata to the server
• definitions of how to convert the input file into something the server can play (example)

So e.g.

sndh flc * *
	# FT:{START=--start=%s}
	[psgplay] -o /dev/stdout --stop=auto --mode=command --psg-mix=linear $START$ $FILE$ | [sox] --multi-threaded --norm=-3 -q -V0 --ignore-length -t wav - -t flac -

to convert from sndh to flac
The server then streams the flac to a player

The name of your device hp-t630 appears to be a 36" large format plotter? I’ve never heard PSG play run on something like a printer device before. :-)

That would be quite impressive (like doombuds), but reality is far more mundane ;-)

This is a problem, since the audio server I'm using only starts converting the next track ~70 sec before the end of the current one. As I can't change this, I'm currently writing a queuing / caching / parallel execution mechanism, but until this works, I can't really use psgplay.

Configuring sufficiently large ALSA buffers seems much simpler to me, to the same effect, no?

This discussion motivated me to have another look at the issue, and I noticed that the server blocked for no apparent reason until the conversion was done. Took me a bit, but I found out that sox is the culprit, since it won't output anything until the audio input has ended when using the --norm option. Without it, it starts immediately.
This basically solves it for most formats (including sndh), but for the really slow ones (e.g. USF) on a e.g. Pi3, it's still a concern, so I'll continue with the solution outlined above (probably mainly because since it's an interesting exercise, tbh)
In the same vein, I'll have a look at switching sndh2wav from the Atari Audio Library to the psgplay library, since I really want to have the option to play all sub tunes.

[frno7]

Thanks, I'll switch to this one from -git btw, I had some issues with psgplay-9999.ebuild: The shared lib failed to build (something about being unable to determine the version), so I changed it to static only:

46c46
<       emake DESTDIR="${D}" install-psgplay install-man || die
---
>       emake DESTDIR="${D}" install || die

which built successfully.

Hmm... I’m unable to reproduce the shared library failure, and the emake commands you cite don’t look like ones I have in the ebuild? Where do they come from? Also, || die shouldn’t be necessary, because as of EAPI 4 “functions provided by Portage will die by themselves if something failed”.

script/version attempts to determine the applicable version. As can be seen in the script, there are two variants:

• If a version file is found in the root of the source directory, it’ll be used. Archives (tar, zip, etc.) need it. My ebuild makes it, because it (previously) downloaded archives from Github (until submodules were required, and Github archives couldn’t be used anymore).
• If the source directory is a Git repo, Git commands are used instead.

As I noted above, I'm not using PSG play stand-alone, but as part of an integration of a number of video game/console/.. music formats (sndh, sid, uade, vgm, psf, ...) into an audio server. This consists of 2 parts:

• a server plugin to supply metadata to the server
• definitions of how to convert the input file into something the server can play (example)

Oh, that’s nice. Issue #16 is somewhat similar, for the Music Player Daemon (MPD).

This discussion motivated me to have another look at the issue, and I noticed that the server blocked for no apparent reason until the conversion was done. Took me a bit, but I found out that sox is the culprit, since it won't output anything until the audio input has ended when using the --norm option. Without it, it starts immediately. This basically solves it for most formats (including sndh), but for the really slow ones (e.g. USF) on a e.g. Pi3, it's still a concern, so I'll continue with the solution outlined above (probably mainly because since it's an interesting exercise, tbh)

Nice!

In the same vein, I'll have a look at switching sndh2wav from the Atari Audio Library to the psgplay library, since I really want to have the option to play all sub tunes.

The --track=<number> option can be used to select subtunes, but maybe Lyrion’s convert.conf doesn’t support the concept of multiple distinct tracks within a single audio file?

[frno7]

As can be seen below, the version comes up in several cases. In the shared library symbolic links and file names:

% equery f media-sound/psgplay
 * Searching for psgplay in media-sound ...
 * Contents of media-sound/psgplay-0.8:
/usr
/usr/bin
/usr/bin/psgplay
/usr/include
/usr/include/psgplay
/usr/include/psgplay/digital.h
/usr/include/psgplay/ice.h
/usr/include/psgplay/psgplay.h
/usr/include/psgplay/sndh.h
/usr/include/psgplay/stereo.h
/usr/include/psgplay/version.h
/usr/lib64
/usr/lib64/libpsgplay.a
/usr/lib64/libpsgplay.so -> libpsgplay.so.0
/usr/lib64/libpsgplay.so.0 -> libpsgplay.so.0.8
/usr/lib64/libpsgplay.so.0.8
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/libpsgplay.pc
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/psgplay.1.bz2

In the pkg-config file:

% cat /usr/lib64/pkgconfig/libpsgplay.pc
prefix=/usr
libdir=/usr/lib64
includedir=/usr/include

Name: psgplay
Description: PSG play is a music player for Atari ST YM2149 SNDH files
Version: 0.8

Libs: -L${libdir} -lpsgplay
Cflags: -I${includedir}

With the --version option:

% psgplay --version
psgplay version 0.8

[dnalor]

Hmm... I’m unable to reproduce the shared library failure, and the emake commands you cite don’t look like ones I have in the ebuild? Where do they come from? Also, || die shouldn’t be necessary, because as of EAPI 4 “functions provided by Portage will die by themselves if something failed”.

Sorry about this - reversed the files for the diff. should have been:

46c46
<       emake DESTDIR="${D}" install || die
---
>       emake DESTDIR="${D}" install-psgplay install-man || die

The ebuild is from your gentoo repo, only modified to include this patch
I can't reproduce this anymore, but I'm pretty sure what happened is that git describe --always --tags returned the "abbreviated commit object", which resulted in a version like "e852f2b". No clue as to why.
My brute-force "solution" was not to build the shared lib and force linking against the static lib
Anyway, seems to have been a local issue, sorry to have wasted your time.

In the same vein, I'll have a look at switching sndh2wav from the Atari Audio Library to the psgplay library, since I really want to have the option to play all sub tunes.

The --track=<number> option can be used to select subtunes, but maybe Lyrion’s convert.conf doesn’t support the concept of multiple distinct tracks within a single audio file?

It doesn't. It would be probably possible to handle it like a CUE file, creating an album with (virtual) tracks for each file, and then including the track number when calling the converter defined in convert.conf, but this seems like a major effort to implement in my plugin for very little if any benefit.
currently, the plugin sums up the times for all sub tunes for the track metadata, and sndh2wav simply starts with the default, and then processes all others, which is what I expect most people would want anyway.

[dnalor]

Since this has evolved into a general Q&A thread, I'd appreciate it if you could outline the major differences between psgplay and the Atari Audio Library.
I've listed all external conversion programs on the plugin's homepage, and I'd like add this info so people can decide which one to use.

[frno7]

It doesn't. It would be probably possible to handle it like a CUE file, creating an album with (virtual) tracks for each file, and then including the track number when calling the converter defined in convert.conf, but this seems like a major effort to implement in my plugin for very little if any benefit. currently, the plugin sums up the times for all sub tunes for the track metadata, and sndh2wav simply starts with the default, and then processes all others, which is what I expect most people would want anyway.

Does the C64 (sidplayfp) plugin for Lyrion operate like that too?

I’m preparing a PSG play plugin for the Music Player Daemon (MPD). Review issue #16. It’s very similar to the preexisting sidplayfp MPD plugin. Both plugins fully support subtunes as ‘virtual’ tracks. Personally, I often cherry-pick individual tracks for playlists etc. :-)

By the way, I’ve added a how to play section to README.md, describing various ways to use PSG play.

Since this has evolved into a general Q&A thread, I'd appreciate it if you could outline the major differences between psgplay and the Atari Audio Library. I've listed all external conversion programs on the plugin's homepage, and I'd like add this info so people can decide which one to use.

Looking at the source code of the Atari Audio Library, it seems to have a simplified model of Atari hardware, especially the MC68901 multifunction peripheral (MFP) timer and interrupt controller. Some SNDH files make the MFP work a lot, so I imagine it’s possible to hear the difference in listening tests. Any emulator may have bugs, of course, and thereby malfunction (more or less) in particular cases. But I should think the difference in (simplification of) the MFP emulation design is audiable in itself, even when the Atari Audio Library is operating as intended.

Have you (or maybe someone else?) compared the two emulators by listening to a good selection of SNDH files?