ali1234
commented
2 years ago Thanks for testing this.
The training split command has a card option in latest git: https://github.com/ali1234/vhs-teletext/blob/master/teletext/cli/training.py#L32
You can use card ddd-tbc instead of slicing the files yourself.
Short .dat files mean some patterns were never observed. This is expected if you use the wrong card type, because lines are checksummed to ensure they are always correctly decoded.
Lots of warnings are also expected because your data has blank lines and video lines in the VBI. Every one will cause a warning. This is not harmful as bad lines are always ignored.
So if you have correctly sized pattern file then it means every possible pattern was correctly observed at least once, which means the training worked as well as it can with the data supplied.
I wouldn't expect the result to be significantly better or worse than the existing patterns. Maybe a little bit better, but perfect decoding is impossible due to bandwidth limitation of VHS. Long play tapes are particularly hard to decode.
itewreed
I recorded trainingdata on tape. Fed it back by using rf capture of video head and letting vhs-decode create the tbc files. Then I fed the luma tbc file through the following script to get a file only containing the vbi lines.
Then I used teletext vbiview to inspect the file. To get correct output I had to add the -c ddd-vbi option. This option is not available for training. So the first round of training threw a lot of Warning: bad line error and the final full, hamming, parity.dat files had different filesize than the files for vhs, betamax and grundig_2x4.
So I did a hack and swapped the name of ddd-vbi with bt8x8 in the Card specific default parameters: section of config.py and repeated the training. Again a lot of bad line warnings appeared, but the filesizes of the training output now were the sames as for the other trained data. I used it to test-decode the teletext and to some degree it worked. But the decoded output still is mostly garbled and doesn't look better than with the already available vhs training data. Two trainings were done. One with 2 hours of standard play, another with 4 hours of longplay. The parameters used for the vhs-decode part were --pal --cxadc3 -nld --threads 4 --recheck_phase
So first of all I'm concerned that something during the training goes wrong, as there are countless of these warnings, The second thing is, the training result performs poorly on actual teletext data.
The following link contains files to reproduce the training. Testdata for reproduction of the issue
ttx240lp_sample.r8 Sample of raw input data to be fed into vhs-decode. The original holds 4 hours of capture ttx240lp_sample.tbc (.json) Already decoded data to be fed to the script mentioned above or maybe directly fed to vhs-teletext vhs-decode-lp_sample.vbi Sample of VBI cutout from the TBC file, longplay vhs-decode-sp_sample.vbi Sample of VBI cutout from the TBC file, standardplay