Clemens Ladisch <clemens-P6GI/4k7KOmELgA04lAiVw(a)public.gmane.org> writes: I think it works even with track marks on continuous play. Not sure about it, though. I need to check whether I have any CDs of that kind: my digital-output CD player is too old to deal with any self-written CDs. Assuming that its belts are still in working order. Huh. Is that an ALSA shortcoming? It would seem like something worth unifying over several drivers capable of S/PDIF. Oh, and what's the deal with Dolby Surround via S/PDIF? That would also need some sort of access different to PCM, wouldn't it? -- David Kastrup

Len Ovens <len-ODU3Ot18rIYsV2N9l4h3zg(a)public.gmane.org> writes: Well, I don't know. I am not forced to use the RME Hammerfall Multiface either: I do have a cheap CM106 based card somewhere as well. The question is whether there is anything in the Linux world that would be able to make use of this S/PDIF information for recording purposes if I got it out. I understand that most people just read out CDs without reverting to S/PDIF (and that's obviously faster), but I don't even know if you can then import toc+track labels into, say, Ardour. But in my case, I have to work with minidisks, and I have no computer-accessible drive, just S/PDIF. -- David Kastrup

David Kastrup wrote: No, of the hardware. The Dolby/DTS bits pretend to be an uncompressed stereo stream. All that changes is a single channel status bit ("non-audio"), which is supported by most cards. Regards, Clemens

Paul Davis <paul-dDzkXPnfpdxaomM2pvQuqZqQE7yCjDx5(a)public.gmane.org> writes: What could the Jack abstraction be? Synthetic Midi signals could likely fit pretty well but probably cannot be delivered sample-accurate. -- David Kastrup

On Wed, Nov 22, 2017 at 1:15 PM, David Kastrup <dak(a)gnu.org> wrote: Sample accurate? Channel status is one _bit_ at a time and is 192 bits wide. That is, for one User Channel word or Channel status word to be derived from incoming data takes 192 samples of time. So jack at 64/2 has better MIDI timing... (taken from ebu tech3250 and tech3250s1 both of which are free to download... unlike AES documents) I was unable to find how dat tape machines encode and send text and marker information. What I could find suggestes spdif is meant to be 20 bit and so it is possible the two least significant bits might be used for other purposes or that the dat is actually still 16 bit and the whole lower 8 bit byte may have information that would allow tighter timing. but 192 samples is the frame rate for most things so I expect that is what is used. With regard to more than 2 channels, any format I know of is not open or free. Even ADAT requires (does it still?) licencing. Certainly anything with the name Dolby attached is closed... that is the only reason they exist. -- Len Ovens www.ovenwerks.net

Len Ovens: ... ... I haven't worked with DAT at all, but in: Michael Dickreiter Handbuch der Tonstudiotechnik 6. verbesserte Auflage pages 320 to 330 covers RDAT (i.e. DAT): Abb. 10/60. Spurschema des RDAT-Formats (in blocks): 11 Vor- bzw. Nachspann (margin) 2 Bittakt-Synchronisation (PLL) 8 Zusatzdaten (subcodes) 1 Abschluß-Kennung (postamble) 3 Blocklücke (Interblock gap) 5 ATF (automatic track findung) 3 Blocklücke (Interblock gap) 2 Bittakt-Synchronisation (PLL) 128 PCM 3 Blocklücke (Interblock gap) 5 ATF (automatic track findung) 3 Blocklücke (Interblock gap) 2 Bittakt-Synchronisation (PLL) 8 Zusatzdaten (subcodes) 1 Abschluß-Kennung (postamble) 11 Vor- bzw. Nachspann (margin) Abb. 10/61. Blockstruktur des RDAT-formats (in bytes): 1 Sync. 1 Ident-Code 1 Block-Adresse 1 Prüf-wort (= ident-code xor block-adresse) 32 Daten-byte Abb. 10/63. Aufbau des Bockadressen-Byte: 0 Ad1 Ad2 Ad3 Ad4 Ad5 Ad6 Ad7 Audiodatenblock 0 ... 127 1 _ _ _ Ad1 Ad2 Ad3 Ad4 Zusatzdatenblock 0 ... 16 There are A and B tracks (+ or - 20° azimuth angle). The data blocks (4kB per track) is in some semi complex way extracted as 1440 geradzahlige abtastwerte 768 Q-Prüfwerte 1440 ungeradzahlige abtastwerte Track A contains L-odd Q R-even Track B R-odd Q L-even The above is the on tape format. Whatever comes out of a connector depends on what type of interface the recorder has. For more information see: Biaesch-Wiebke, C.: CD-Player und R-DAT-Recorder, 1. Aufl. 1988, Vogel Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57

Clemens Ladisch <clemens-P6GI/4k7KOmELgA04lAiVw(a)public.gmane.org> writes: Huh. This begs the question: are there any applications making use of it? For example, for recording via S/PDIF including track marks? Or anything else? -- David Kastrup

Clemens Ladisch <clemens-P6GI/4k7KOmELgA04lAiVw(a)public.gmane.org> writes: Pfffft. Well, it would explain why there are no programs making use of it. Basically my option would then be to acquire an audio CD recorder with digital input and record the minidiscs (copy protection bit permitting) to CD from which I use cdparanoia et al to get the full information. Possibly putting the Hammerfall as pass-through in the middle, hoping that it will pass on the user/subcode bits while clamping down on copy protection. Yes, that sounds overoptimistic: there is no obvious reason why anything but PCM data should make it through its Totalmix. Or I hope that recording a copyright-bit plagued Minidisc will at least record _structured_ silence. In which case I can at least get the structure on CD. This is all rather icky. Does anybody using other operating systems know whether the situation is basically the same there? -- David Kastrup