*** TIPS & TRICKS MENU

CD Recording
Clipper

* CD Recording
------
How to compare two wave files
I was glad to open this page with a small (but useful, I hope!) utility not strictly related to Taiyo's owners.
I think that there's nothing simpler than compare two files.
But, if these files are wave files, the problem may become a little harder. Actually, if you're use to perform DAE and/or burn audio CDs, you know that is pretty usual to find a slight offset between files; or a series of burst.
This very common behaviour may invalidate the match test.
I've found on the net many freeware or shareware utilities, with a nice graphical user interface, but none of these satisfied my primary need: the quick validation of a Digital Audio Extraction (or of a burning process) in order to optimize the settings of the softwares (e.g. speed and jitter correction) and the choice of the recordable CD brand.
So I've written WaveDiff, a little command-line utility that compares two wave files (CD format only, i.e.: 16 bits, stereo, 44kHz). I'm waiting for your comments.
Known bug: the wave compare fails to sync if there is a constant waveform in the beginning of the files (i.e. zero samples, silence) because WaveDiff searches for the sync just in a predefined small time window; this window is usually smaller than the intro silence. This misfunction occurs tipically when you compare the first tracks of a CD. If you are interested, this incorrect behaviour will be fixed in the future release (depending on your feedback).

Return to the menu

* Clipper
------
Serial communication
In the past I've implemented a doorway system inside one of my Clipper program using CA Tools III (over specification at 57600 bps!). The system worked fine, although the misunderstanding of many bytes due to the high speed required a severe software CRC control and a basic correction protocol.
Recently I've found on the Phil Barnett's Oasis the CLIOLib, supporting reliably up to 115200 bps. However I've found a serious bug in the fundamental OUTCHR function. So, if you need to use this wonderful Bruce Raisley's lib, get rid of the OUTCHR function and use instead the OutC function that seems to work perfectly. Please note that I currently develop under 5.2e linked with RTLink.
With CLIOLib and a common Rockwell-chipset modem I've developed a televoting system and a fax-on-demand system.
------
Networking (something strange on Win95)
Since the old good times of Netware Lite I've always developed multi-user apps without any kind of problem. I tested locking schemes and so on in the dos boxes of Windows for Workgroup (not so bad as claimed) and now, with better results, of Win 95. My customers are using 10BaseU or 10BaseT Ethernet networks, with previously IPX/SPX and now NetBEUI and TCP/IP protocols. Usually I configure a TCP/IP 192.168.x.x subnet in order to install a proxy server, HP Jetserver and so on.
A first bad symptom some month ago, when a Win 95 OSR2 server became client: a serious index corruption unsolved with the first Microsoft VREDIR update found on the Phil Barnett's Oasis but fortunately solved with a more recent VREDIR Microsoft patch NOT found on the Microsoft's site :-( but now uploaded on the Oasis too.
No problems at all since a few weeks ago. The networks become unstable, a really nightmare: randomly interruptions occurred with X-files locking errors and abnormal program ending. I think this is not a RTFMF problem, because I was not able to find anything on the net about that.
I've found the solution by chance, and I still I don't know why. You've to get rid of the NetBEUI protocol. Leave the TCP/IP alone and all returns to work great.
As side effect, avoiding NetBEUI, the ATX close procedure on Win98 doesn't hang more.
This workaround seems to solve other X-files problems (also if you don't have any Clipper application to run). So leave the TCP/IP alone: you can continue to see your network neighbourhood, you can share your directories and your printers and, finally, the throughput seems to be slightly higher.

Return to the menu