Questions about ".Wav" Files in OpenMSX.

Page 2/3
1 | | 3

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

19-06-2014, 15:27

@saccopharynx One of the reasons is that with OpenMSX you can actually save to WAV-file, but not to CAS-file... When you have just written a nice big BASIC-listing and you want to save it to cassette, you get a shotgun and try to shoot someone if some autoload feature discards all your work and decides to load a game. The other valid reason is that there is currently no mechanism to detect file type from WAV-files in OpenMSX as that is many times harder than with CAS-files.

By Manuel

Ascended (18256)

Manuel's picture

19-06-2014, 18:06

Some other points:
- a common use case is run a cassette game. You boot the MSX with the CAS file inserted. It will load automatically. Convenient! No need to look up the loading instruction, no need to type.
- the chance that it destroys your work is really really small. You would have to be inserting a CAS file. Why would you do that while programming a basic listing? If you did anyway, just use reverse to undo the action.
- how many people will insert a CAS file and do NOT want to run it immediately? Can you sketch an example?
- DSK files have their own native auto run functionality. So you can't compare with that. It's not possible to implement an auto run for disk files, you wouldn't know what file to run.
- Indeed, only for CAS, because for WAV it's practically impossible (OK many times harder is a good way to say it) to detect the format. Fits nicely for the intended use case: run games. Practically all tape games one would run are CAS files.

So, I think the chance that you encounter the feature when not wnated is really small and the chance that someone benefits from it is really high. That's why I made it enabled by default... Why let the rare down side cases cause less convenience for most users?

By saccopharynx

Master (165)

saccopharynx's picture

20-06-2014, 04:37


Quote:

NYYRIKKI... When you have just written a nice big BASIC-listing and you want to save it to cassette, you get a shotgun and try to shoot someone if some autoload feature discards all your work and decides to load a game.


Even though the action can be reversed as Manuel explained, I do not think that such a particular behaviour properly emulates an MSX. Besides, the undo actually applies to an experienced user that widely knows openMSX features. Regular users might be in trouble.

But apart from that (let's assume that such a behaviour is what everyone likes) there is still something a bit controversial with openMSX (Manuel, please take this as a constructive feedback rather than bad criticism; I actually love opneMSX so the more precise it becomes, the better). To my understanding, the philosophy applied to openMSX has always been to perfectly (or almost precisely) emulate MSX hardware and right use procedures. That is why, for example, when connecting an IDE interface we have to type commands like "set power off" and "set power on" in between of the change of the hard disk image. Even though this is not very handy and direct like simply allowing to change the hard disk image and restarting openMSX, it greatly recreates the recommended operation on an MSX.

So, if the aim of openMSX is basically to resemble MSX hardware/behaviour as much precise as possible, why no to leave the cassette auto-run feature off by default?

In addition, since this topic has shown some limitations in the use of WAV files (e.g., it is very hard to detect the file type), maybe it is not a bad idea to "re-consider" the implementation of the TSX format (as long as it actually brings efficient solutions to known limitations).

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

20-06-2014, 10:23

saccopharynx wrote:

maybe it is not a bad idea to "re-consider" the implementation of the TSX format (as long as it actually brings efficient solutions to known limitations).

I think the TSX-format got a bit bad start because it was considered too literally TZX-like format... Let's call the new format ie. "CAS 2.0"-format and I think that many more people will start to like the idea... I think think some content based, but accurate format would be "right thing to do", so I still vote yes.

By bore

Master (135)

bore's picture

20-06-2014, 12:38

Just a small thing regarding wav files. The riff container supports adding custom chunks and programs are supposed to ignore but preserve unknown chunks.
Adding chunks with start position, file type and file name should be compatible with correctly written audio players. Sample editors may or may not throw them away depending on if they follow the specification or not.

By hit9918

Prophet (2911)

hit9918's picture

20-06-2014, 17:50

openmsx cas autorun, I haven't seen it, but I wonder whether this is a way to handle it:

as you insert casette, the gui flips to the typing box and the instructions are in there.
then the user can decide whether he presses the "type" button.

now the thing is easily explainable in openmsx manual.
"as you insert a cas, the gui suggests what to type, press type button to get it done".

By hit9918

Prophet (2911)

hit9918's picture

20-06-2014, 22:00

@Nyyrikki, the format exists, it is TTL wav.

Try out TTL wav now:
load "analog" wav to audio app. crank up its volume "as much as tool can do". allow clipping.
if still not all samples hit the roof, repeat the crank up.
save the file as wav - you are saving a TTL wav.

zip the wav and observe the file size.
as first step try whether it loads in openmsx.

"content based". this is performed by wav. filetypes. length of sync header. bload addresses. you name it.
unknown surprise custom format still can be preserved.

"but accurate format". this is performed by TTL wav.
The clear accurate one is the TTL wav containing just the 4 PPI states per bit: PPI wav.
Main advantage is lower file size. And no corner cases with different interpreter algorithms. a pure bitstream. still containing sync header length info.

loaders are adviced to cope with analog wav.
savers are adviced to store PPI wav.

By sd_snatcher

Prophet (3486)

sd_snatcher's picture

06-03-2016, 02:30

While creating a backup for the Robocop tape version, I found out that it wouldn't work with sample rates lower than 44.1KHz. In 16bit mono, that resulted in a 76MB file per side. Compressing them to zip would result in an almost insignificant compression, reducing each one to around 72MB.

OTOH, openMSX successfully supported that the wav files were compressed with the IMA ADPCM algorithm. This resulted in 18MB per side files, that could be further compressed with zip to 12MB per side.

By Grauw

Ascended (10181)

Grauw's picture

06-03-2016, 16:04

In theory the wav has a lot of repetitive data which should compress very well. However this only works when the signal is clean and not noisy. It would be really great if at some point someone developed a simple-to-use tool to clean up the WAV files.

By Wild_Penguin

Hero (641)

Wild_Penguin's picture

06-03-2016, 17:46

Grauw wrote:

In theory the wav has a lot of repetitive data which should compress very well. However this only works when the signal is clean and not noisy. It would be really great if at some point someone developed a simple-to-use tool to clean up the WAV files.

Years ago when I was recording old tapes myself, I stumbled upon "regenerador" -utility. I think it was in Spanish only. This is exactly what it claims to do, but I haven't tested how much it affects compression.

The page it used to be available (with sources) for download seesm to be gone... if you need it, ask (I think I still have it on my HD).

Page 2/3
1 | | 3