eti-cmdline: not able to generate DAB+ ETI file about eti-stuff

[andimik]

Could you please upload this file and post all messages?

What source do you use? How is the reception?

[aleena57]

ETIPlayer: playing sub-channel 0 (DAB+)
ETISource: reading from 'dabplustest2.ETI'
FICDecoder: SubChId 0: start 0 CUs, size 96 CUs, PL EEP 3-A = 128 kBit/s
FICDecoder: SId 0xE001: audio service (SubChId 0, DAB+, primary)
FICDecoder: SId 0xE001, SCIdS 0: MSC service component (SubChId 0)
FICDecoder: EId 0xE000: ensemble label 'REDWOOD'
FICDecoder: SId 0xE001: programme service label 'REDWOOD SRV00'
(0+) SuperframeFilter: Superframe sync started...
(0+) SuperframeFilter: Superframe sync succeeded after 1 frame(s)
ETIPlayer: format: HE-AAC v2, 48 kHz Stereo @ 128 kBit/s
AACDecoder: using decoder 'FAAD2'
SDLOutput: using audio buffer of 192000 bytes
SDLOutput: audio opened; driver name: pulseaudio, freq: 48000, channels: 2, size: 9216, samples: 1152, silence: 0x00, output: 32bit float
(AU #2) (5+) (AU #2) (0+) (AU #2) (0+) (AU #2) (0+) (AU #2) SDLOutput: silence started...
(5+) (AU #1) (AU #2) SDLOutput: silence ended (9216 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (30720 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (15360 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (15360 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (15360 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (15360 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (15360 bytes)
SDLOutput: silence started...
(0+) (AU #2) SDLOutput: silence ended (6144 bytes)
SDLOutput: silence started...

[aleena57]

source is REDWOOD streamer.

[andimik]

Ok, then the file should be error-free of course.

[aleena57]

Ok, then the file should be error-free of course.

Then what would be the issue?

[basicmaster]

This is difficult to say without having the actual ETI file. I tend to assume that the file content is not 100% correct for some reason. Is it this device with which you created the mux?

And with which hardward/software did you get the signal to DABlin? This cannot be seen in the posted logs, as you just play the file dabplustest2.ETI here.

Could you upload the ETI file somewhere? A minute or so would be enough, if it is too large.

BTW did you also open #39 some days ago?

[aleena57]

Is it this device with which you created the mux? Yes
And with which hardward/software did you get the signal to DABlin? dabstick
https://drive.google.com/open?id=1DFGApCGd-1esjQ3SQyay9nzCPyJceM4u

[JvanKatwijk]

we can see that the eti file does not give the good results, but can we get a recording of the input? with an input file I can do some checking and see where things go wrong Op ma 21 jan. 2019 om 14:24 schreef aleena57 <[email protected]>:

…

Is it this device with which you created the mux? Yes And with which hardward/software did you get the signal to DABlin? dabstick https://drive.google.com/open?id=1DFGApCGd-1esjQ3SQyay9nzCPyJceM4u — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwOT8ZFeoj9AkWibslph0R5ogp-_jks5vFb-WgaJpZM4aKC2Y> .

-- Jan van Katwijk [phone] [phone]

[aleena57]

I don't have recording of input. I only have the eti file.

[andimik]

You wrote you made the recording with a dabstick. So you can write the input file (raw or sdr file).

[JvanKatwijk]

I ran a quick test and I noticed that the reed-solomon decoding for DAB+ frames consistently give more errors than can be repaired. Are we sure that the incoming data is correct? Op di 22 jan. 2019 om 06:59 schreef andimik <[email protected]>:

…

You wrote you made the recording with a dabstick. So you can write the input file (raw or sdr file). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwLvXMbYGMR2HiEYsEKWmsVlv6MNXks5vFqjcgaJpZM4aKC2Y> .

-- Jan van Katwijk

[JvanKatwijk]

I ran some further tests and it shows that the data in the MSC is corrupted, the data in the FIC is apparently not. Looking at the et-cmdline sources (which I did not do for quite a while) shows that handling the MSC is unaware of the kind of service carried in the MSC, it handles "subchannels", so DAB, DAB+ and data channels are all handled the same. So it is really necessary to get the incoming data. Until then I cannot be certain that the incoming data is correct Op di 22 jan. 2019 om 11:51 schreef jan van katwijk <[email protected]

…

: I ran a quick test and I noticed that the reed-solomon decoding for DAB+ frames consistently give more errors than can be repaired. Are we sure that the incoming data is correct? Op di 22 jan. 2019 om 06:59 schreef andimik ***@***.***>: > You wrote you made the recording with a dabstick. So you can write the > input file (raw or sdr file). > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#40 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AITzwLvXMbYGMR2HiEYsEKWmsVlv6MNXks5vFqjcgaJpZM4aKC2Y> > . > -- Jan van Katwijk

-- Jan van Katwijk

[basicmaster]

• as far as I understand Opendigitalradio/dablin#21 (comment), DAB (MP2) works fine
• the first and the second AU of the three AUs of almost every Superframe is error free (all CRCs correct)...the third AU never though...such a pattern certainly cannot result from a lower layer
• the PAD of the error-free AUs is not compliant (the typical X-PAD len issue; use dablin_gtk instead of dablin to get the log messages)

So my current assumption is that the generator already outputs faulty DAB+. At least the PAD is affected...

[andimik]

So let's wait until we get a rawfile

[JvanKatwijk]

Agree Op 22 jan. 2019 21:09 schreef "andimik" <[email protected]> het volgende:

…

So let's wait until we get a rawfile — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwJa4AqJyYAg_FnzVBMHCq9jcEAh4ks5vF3AHgaJpZM4aKC2Y> .

[aleena57]

Thank you all. I got it sorted by changing bitrate in streamer.

[andimik]

You mean the sampling rate?

[basicmaster]

@aleena57: While your issue is solved now, it would be really helpful if you could provide the raw dump anyway, so that we can investigate if there is an issue on our side. I don't think so, but I would like to be sure ;-)

[JvanKatwijk]

It seems @aleena57 does not react anymore on the question to make the input available, so I suggest to close the issue. However, it seems not quite in line with the net-etiquette to not answer, since we all spent time addressing his/hers question.
The question whether or not he/she also was responsible for issue #39 was also not answered.
Sad

[basicmaster]

Yes, it's indeed annoying when people take, but don't give back....this would be the least...