Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.sinclair > #1782 > unrolled thread

audio to .tzx conversion: a "lost bit" issue?

Back to article view | Back to comp.sys.sinclair

Contents

  audio to .tzx conversion: a "lost bit" issue? Ivan Shmakov <oneingray@gmail.com> - 2013-01-17 19:36 +0000
    Re: audio to .tzx conversion: a "lost bit" issue? "Brian Gaff" <Briang1@blueyonder.co.uk> - 2013-01-18 09:14 +0000
      Re: audio to .tzx conversion: a "lost bit" issue? Ivan Shmakov <oneingray@gmail.com> - 2013-01-18 19:41 +0000
        Re: audio to .tzx conversion: a "lost bit" issue? "Daniel Mandic" <daniel_mandic@hotmail.com> - 2013-01-18 20:13 +0000
    Re: audio to .tzx conversion: a "lost bit" issue? Fred <fredm@spamcop.net> - 2013-01-18 06:53 -0600
      Re: audio to .tzx conversion: a "lost bit" issue? Ivan Shmakov <oneingray@gmail.com> - 2013-01-21 08:59 +0000
        Re: audio to .tzx conversion: a "lost bit" issue? Fred <fredm@spamcop.net> - 2013-01-22 14:52 -0600

#1782 — audio to .tzx conversion: a "lost bit" issue?

	FWIW, I've got some rather old (as in: early 90'ies) ZX Spectrum
	tapes, and now trying to read them into .tzx files.  After
	digitizing one of the tapes and running over some SoX [1] tweaks
	(to apply some gain, and select just one of the channels), I've
	finally got audio2tape(1) (as bundled with the FUSE emulator
	[2]) to recognize the data... almost: it seems to lose one bit
	to one byte of data in the process.  Consider, e. g.:

Block ended, found 18 bytes
Type: Data
Error have incomplete byte (7 bits)
First block seconds: 19.6456
Last block seconds: 24.5804
Checksum:FAIL

	This block looks like a standard 19-bytes Spectrum header
	(presumably for a BASIC program, as this is the first block on
	the side), but only with the last bit lost.

Block ended, found 260 bytes
Type: Data
Error have incomplete byte (3 bits)
First block seconds: 25.5527
Last block seconds: 28.7592
Checksum:FAIL

Block ended, found 47 bytes
Type: Data
First block seconds: 28.7607
Last block seconds: 29.0521
Checksum:FAIL

Block ended, found 18 bytes
Type: Data
Error have incomplete byte (7 bits)
First block seconds: 33.9866
Last block seconds: 38.9156
Checksum:FAIL

	This block looks like one more header (sans the trailing bit)...

Block ended, found 6911 bytes
Type: Data
Error have incomplete byte (6 bits)
First block seconds: 39.8885
Last block seconds: 76.5504
Checksum:FAIL

	... And this one looks (and, well, sounds) just like a SCREEN$
	file data, yet again -- with a couple bits lost (of the usual
	6912 bytes.)

	Any idea what may be happening there, or what else could I try?

	TIA.

[1] http://sox.sourceforge.net/
[2] http://fuse-emulator.sourceforge.net/

-- 
FSF associate member #7257

[toc] | [next] | [standalone]

#1786

I could understand losing the first, especially if you have a gain riding 
system in place so its either too loud or too quiet. I've found that the 
less processing done in digital side the better, ie its far better to adjust 
azimuth and maybe use just one of the channels and get a good clean 
recording, than to bother with attempting to make the recording  quieter or 
smooth out minor volume fluctuations. Pick the stereo channel with the least 
dropouts. You can even swap channels at file ends if the dropouts are fewer 
on the other one. attempting to use both as a mono mix tends to fail due to 
the skewing of old tape as it weaves across the head.

Brian

-- 
From the Sofa of Brian Gaff Reply address is  active
"Ivan Shmakov" <oneingray@gmail.com> wrote in message 
news:87k3rbbo08.fsf@violet.siamics.net...
> FWIW, I've got some rather old (as in: early 90'ies) ZX Spectrum
> tapes, and now trying to read them into .tzx files.  After
> digitizing one of the tapes and running over some SoX [1] tweaks
> (to apply some gain, and select just one of the channels), I've
> finally got audio2tape(1) (as bundled with the FUSE emulator
> [2]) to recognize the data... almost: it seems to lose one bit
> to one byte of data in the process.  Consider, e. g.:
>
> Block ended, found 18 bytes
> Type: Data
> Error have incomplete byte (7 bits)
> First block seconds: 19.6456
> Last block seconds: 24.5804
> Checksum:FAIL
>
> This block looks like a standard 19-bytes Spectrum header
> (presumably for a BASIC program, as this is the first block on
> the side), but only with the last bit lost.
>
> Block ended, found 260 bytes
> Type: Data
> Error have incomplete byte (3 bits)
> First block seconds: 25.5527
> Last block seconds: 28.7592
> Checksum:FAIL
>
> Block ended, found 47 bytes
> Type: Data
> First block seconds: 28.7607
> Last block seconds: 29.0521
> Checksum:FAIL
>
> Block ended, found 18 bytes
> Type: Data
> Error have incomplete byte (7 bits)
> First block seconds: 33.9866
> Last block seconds: 38.9156
> Checksum:FAIL
>
> This block looks like one more header (sans the trailing bit)...
>
> Block ended, found 6911 bytes
> Type: Data
> Error have incomplete byte (6 bits)
> First block seconds: 39.8885
> Last block seconds: 76.5504
> Checksum:FAIL
>
> ... And this one looks (and, well, sounds) just like a SCREEN$
> file data, yet again -- with a couple bits lost (of the usual
> 6912 bytes.)
>
> Any idea what may be happening there, or what else could I try?
>
> TIA.
>
> [1] http://sox.sourceforge.net/
> [2] http://fuse-emulator.sourceforge.net/
>
> -- 
> FSF associate member #7257 

[toc] | [prev] | [next] | [standalone]

#1788

>>>>> Brian Gaff <Briang1@blueyonder.co.uk> writes:

[...]

 > Pick the stereo channel with the least dropouts.

	Indeed, switching to a single channel led to an instant
	improvement!  Still, there's way too much unreadable blocks, but
	at the least, the headers seem to be recognized now.

[...]

	Re. the analog vs. digital: I'm trying to get the "best"
	digitization in the least number of tries (so to minimize the
	wear.)  Unfortunately, there's a little chance that I could get
	some Hi-Fi equipment for the analog part of the processing (why,
	it was a considerable luck that I was able to find /any/
	cassette player these days; and then, I've already had to repair
	it after less than a hour of use.)

	I could probably try my luck at adjusting the head (or checking
	the electronics; say, for dried electrolytic capacitors) given a
	"test" cassette with some known signal recorded.  But there's a
	little hope that I could find one, or that I could record it
	myself.

	Thus, digital processing seems like my only hope.

-- 
FSF associate member #7257

[toc] | [prev] | [next] | [standalone]

#1789

Ivan Shmakov wrote:
 
> 	Re. the analog vs. digital: I'm trying to get the "best"
> 	digitization in the least number of tries (so to minimize the
> 	wear.)  Unfortunately, there's a little chance that I could get
> 	some Hi-Fi equipment for the analog part of the processing (why,
> 	it was a considerable luck that I was able to find any
> 	cassette player these days; and then, I've already had to repair
> 	it after less than a hour of use.)

AKAI GX 75-II....
 
> 	I could probably try my luck at adjusting the head (or checking
> 	the electronics; say, for dried electrolytic capacitors) given a
> 	"test" cassette with some known signal recorded.  But there's a
> 	little hope that I could find one, or that I could record it
> 	myself.

A try on an azimuth-self-adjusting Nakamichi Dragon Or Cr4 Tape Deck
might help. Maybe....

> 	Thus, digital processing seems like my only hope.

?

How can you recover something what can't be read properly?


-- 
Daniel Mandic

[toc] | [prev] | [next] | [standalone]

#1787

Ivan Shmakov <oneingray@gmail.com> wrote:
> 
> 	Any idea what may be happening there, or what else could I try?

It's important to get as much signal to noise as possible. Try recording
with the volume just short of clipping as just using sox to increase volume
alone will also increase noise. 

Could you post the wav somewhere so others can have a look and try as well?

Fred

[toc] | [prev] | [next] | [standalone]

#1796

>>>>> Fred  <fredm@spamcop.net> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> wrote:

 >> Any idea what may be happening there, or what else could I try?

 > It's important to get as much signal to noise as possible.  Try
 > recording with the volume just short of clipping as just using sox to
 > increase volume alone will also increase noise.

	This makes sense, although the whole problem with clipping is
	that you don't know it have occurred until after the fact.  So,
	I've tried to allow for some "headroom" while digitizing the
	records, just in case the volume would suddenly rise in the
	middle of the tape.

	Also, I've tried two more cassette players I was able to find
	around here, and stopped on the last of them.  So far, I was
	able to successfully produce a few .tzx'es.  (Well, at the
	least, the software appears to load fine from these.  I guess I
	should check the data against the WoS archive, as some of the
	software on these cassettes could also be found there.)

	Two more factors are that I've tried the other cassettes I have
	(so perhaps those I've tried initially were faulty), and that
	I've applied a bandpass filter (as per SoX' "sinc 640-13440"),
	as otherwise the sync pulse was failing to cross the zero line
	more than just occasionally.  Also, this levels the amplitudes
	of the frequencies used somewhat.

	(BTW, is it a feature of ZX tape records that the higher of
	these frequencies has noticeable lower amplitude than that of
	the lower one?  Or is it my hardware's fault?  One more issue
	with that is that the signal's "trail" may be of amplitude
	almost matching that of the higher frequency, so that
	audio2tape(1) considers it an extra bit; which, naturally, makes
	the number of bits in the stream, sans the sync pulse and the
	parity bit, not divisible by 8.)

 > Could you post the wav somewhere so others can have a look and try as
 > well?

	I guess so, should I ran into issues once again.

-- 
FSF associate member #7257

[toc] | [prev] | [next] | [standalone]

#1797

Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>> Fred  <fredm@spamcop.net> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> wrote:
> 	(BTW, is it a feature of ZX tape records that the higher of
> 	these frequencies has noticeable lower amplitude than that of
> 	the lower one?  Or is it my hardware's fault?

That is quite normal and I think relates to the filtering effectively
applied by the tape medium and player. 
  
> 	One more issue with that is that the signal's "trail" may be of amplitude
> 	almost matching that of the higher frequency, so that
> 	audio2tape(1) considers it an extra bit; which, naturally, makes
> 	the number of bits in the stream, sans the sync pulse and the
> 	parity bit, not divisible by 8.)

The different trigger type options can potentially help with that though
audio2tape is pretty basic when It comes to dealing with low quality source
data. 

Fred

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.sinclair

csiph-web