Stereo Tool
https://forums.stereotool.com/

Stereo Tool 9.00
https://forums.stereotool.com/viewtopic.php?f=14&t=24966
Page 18 of 29

Author:  \_/ [ Wed Jul 11, 2018 11:21 am ]
Post subject:  Re: Stereo Tool 9.00

:o Opening WinRAR 5.60 or a RAR-archive makes the ST-GUI of beta 8 flicker white for a moment. All other software I tested was ok. Windows 10 Pro x64 17134.165

Author:  hvz [ Wed Jul 11, 2018 2:06 pm ]
Post subject:  Re: Stereo Tool 9.00

Stereo Tool 9.02 BETA010


Please note: Not only Stereo Tool, but also the MicroMPX encoder that's now built into this Stereo Tool build is a beta version.

Known issues:
- MicroMPX doesn't work if FM output sound card is enabled in ASIO mode and the sample rate is set lower than 176400 Hz.
- One user reported very bad/distorted audio, we're still investigating what's wrong. On our end it's fine, so it's probably caused by some specific chipset...

Windows 32 bit:
Windows stand alone: https://www.stereotool.com/download/ste ... 02-010.exe
Winamp DSP: https://www.stereotool.com/download/dsp ... 02-010.exe
VST: http://www.stereotool.com/download/vst_ ... 02-010.dll
MicroMPX web based decoder: https://www.stereotool.com/download/Mic ... 02-010.exe
MicroMPX web based encoder: https://www.stereotool.com/download/Mic ... 02-010.exe
MicroMPX command line enc/dec: https://www.stereotool.com/download/Mic ... 02-010.exe
libsndfile-1.dll (needed for MicroMPX decoder and command line version, place in same directory): MicroMPX command line enc/dec: https://www.stereotool.com/download/libsndfile-1.dll

Windows 64 bit:
Windows stand alone: https://www.stereotool.com/download/ste ... 02-010.exe
VST: https://www.stereotool.com/download/vst ... 02-010.dll

ARM (Raspberry Pi 2/3 etc) 32 bit:
MicroMPX web based decoder: https://www.stereotool.com/download/Mic ... ETA902-010
MicroMPX web based encoder: https://www.stereotool.com/download/Mic ... ETA902-010
MicroMPX command line enc/dec: https://www.stereotool.com/download/Mic ... ETA902-010


CHANGES:
  • Added MicroMPX encoder to Stereo Tool!
  • Add ThimeoKoekError to Stereo Tool
  • uMPX decoder: Not stable with password protection, and asserts on bad data (should just print a warning)
  • uMPX: decoder: Check password activation on startup
  • uMPX decoder: License was saved in current directory, which fails in Program Files.
  • uMPX decoder: Ignore ticks for too late packets
  • Redesign ClockShift - seems better than before (needed to measure sound card sample rate offset - to keep MicroMPX decoder in sync)

    OLD CHANGES:
  • Multiband 2 clipper default values were taken from earlier version and set to -infinity dB, leading to silence (BETA004).
  • GUI priority is too low now (BETA003/004) - removed lowering it for plugin version.
  • GUI: 4K weird flashing since last Windows update
  • RDS: Support for ODA. probably ok
  • RDS: Support for EON Partially working, need to add burst mode, linkage, freqs, turning on/off via command
  • RDS: EON: Support for multiple AF frequencies
  • MicroMPX crashes on closing -> Join thread was missing
  • uMPX: Add entering & applying hash
  • uMPX encoder: Add new settings to separate encoder
  • uMPX decoder: Add password + hash
  • SST build fails, incorrectly including something from MicroMPX somehow?
  • Made MB clipper completely separate from limiter, so you can now use both at the same time
  • Input level meter can flash black on Mac. Cause unknown, doesn't really reproduce in a clear way. -> Value was set to 0 after displaying and could be displayed again before a new value was set.
  • Output scope runs too slow in certain situations
  • Output scope can lag behind (GuntherM) -> Probably fixed by previous fix, waiting for feedback
  • Check uMPX disabled when FM disabled -> Yes, but GUI wasn't.
  • Mac VST plugin didn't work.
  • Add MB clipper to MB1 as well. Decide if limiter AND clipper needed simultaneously (probably not?)
  • Update build script - remainder - Woohoo, full build now takes 12 hours (was 30)
  • Add MB clippers
  • Lower GUI thread priority for plugin versions.
  • Make Windows event thread priority equal to GUI thread priority. (Affinity was already ok)
  • Set minimum size on VST version (1500x843)
  • Update build script for much faster build - partially done

    PLANNED:
  • Check MB1 clip display -> Was indeed missing, fixed.
  • Update preset Dutch Moose
  • Add sweep tone
  • Add MagicRDS hex number support
  • Fix bug: MicroMPX encoder does not get activated (and "Force generate composite doesn't work either) when the FM output is running in ASIO mode at 44/48 kHz. -> Changed, now the FM output will play silence and show an error message in this situation.
  • Add more sweep tones
  • MicroMPX sounded very bad in 64 bit Stereo Tool build - wrong compiler setting for 64 bit, fixed.
  • MicroMPX: Can't handle "Ignore high frequencies" values other than 19200.
  • ClockShift redesign: Extremely heavy now.
  • c0000409 error Added logging
  • Update presets Wes
  • Redesign ClockShift with median
  • Optimize ClockShift after getting confirmation that it now works well
  • Bug report: Linux version uses 100% CPU on one thread, even in bypass mode (must be sound card thread?) -> Not here. Not sure what's going on.....
  • MicroMPX: Error when changing IP address in GUI
  • MicroMPX: highs idea
  • Test 64 bit sound card exception handling in ProppFrexx - that wasn't the problem... apparently
    -
  • RDS: EON: Support for other type of AF frequencies?
  • RDS: Support for AF method B
  • Brian, NAB
  • MOBO
  • Delay on handling changed IP/port numbers. Or smart queue which removes duplicates
  • uMPX encoder/plugin: Sound card speed message
  • uMPX decoder: Add multicast subscribe
  • Add MagicRDS AF method B support

Author:  PatrickvdHoek [ Wed Jul 11, 2018 5:47 pm ]
Post subject:  Re: Stereo Tool 9.00

Hi Hans,

Testing with StereoTool latest BETA. The AF frequencies from MagicRDS is not right. For example, RDS Spy returns 90.9 FM as an alternate frequency, but I've set up MagicRDS to push 92.7. Also MagicRDS is set up to use AF method A, but RDS Spy is returning B. I'm currently not able to fly to Spain because of an accident I recently had, but is RDS Spy reporting right or not?
Using UECP ASCII mode.

See attached images. I've setup when there is a specific title in the Now Playing TT file to disable the AF function (return no AF channels) and otherwise return AF=A & AFCH=34.

All other RDS functions are working properly.

Best,
Patrick

Attachments:
Schermafbeelding 2018-07-11 om 17.47.15.png
Schermafbeelding 2018-07-11 om 17.47.15.png [ 15.72 KiB | Viewed 3626 times ]
Schermafbeelding 2018-07-11 om 17.45.22.png
Schermafbeelding 2018-07-11 om 17.45.22.png [ 31.75 KiB | Viewed 3626 times ]

Author:  hvz [ Wed Jul 11, 2018 5:51 pm ]
Post subject:  Re: Stereo Tool 9.00

Quote:
Hi Hans,

Testing with StereoTool latest BETA. The AF frequencies from MagicRDS is not right. For example, RDS Spy returns 90.9 FM as an alternate frequency, but I've set up MagicRDS to push 92.7. Also MagicRDS is set up to use AF method A, but RDS Spy is returning B. I'm currently not able to fly to Spain because of an accident I recently had, but is RDS Spy reporting right or not?
Using UECP ASCII mode.

See attached images. I've setup when there is a specific title in the Now Playing TT file to disable the AF function (return no AF channels) and otherwise return AF=A & AFCH=34.

All other RDS functions are working properly.

Best,
Patrick
I'll check what's wrong tomorrow. AF method A or B are identical in how they are transmitted though, so I don't know how RdsSpy can determine which of the two it is.

According to the RDS spec:
Quote:
3.2.1.6.5 Convention for identification of the AF methods used
The AF method used is not signalled explicitly, but can easily be deduced by receivers from the frequent repetition of the tuning frequency in the transmitted AF pairs in the case of AF method B.
Since there's only one, there's no way of knowing (well. Basically, it's AF method A then because for B you need pairs). (And yes. We also thought that this is a very strange way of doing things......)

By the way. The way of turning AF off might not work - radio's are supposed to remember the list of frequencies. What you should actually do is use AF method B (which I am planning to implement very soon! I've already added ODA for TMC etc, IH, EWS and EON last week - all only via UECP though, since that's a defined standard, and strings like AFCH=34 is not...).



Edit: Ok. I quickly peeked in my code. AF frequecies are listed like this:
1 = 87.6 (you can't officially send 87.5! Because 0 has a different meaning. Some receivers do accept it though.)
2 = 87.7
3 = 87.8
4 = 87.9
5 = 88.0
...

Anyway, if you count like this, 34 = 90.9. 51 = 92.6. Where did you find that you should send 34 for 90.9? I can't think of any logical way how that would match, because everything would need to shift by 16 places - 87.6 would be -14 or -15 or something like that.


By the way. The fact that no special signalling is used means that it's actually possible already to send AF method B data as things are now. Just make sure that you're sending the correct pairs.

Author:  PatrickvdHoek [ Wed Jul 11, 2018 6:04 pm ]
Post subject:  Re: Stereo Tool 9.00

I've set up the AF frequency in the dialog "AF", and monitored the Command Log Windows for what command is being sent to the UECP port.
But it's not 90.9, it should be 92.7 which is 34 in MagicRDS.

Or you should make a command available to the StereoTool GUI to disable AF with a special command to interrupt the AF's while broadcasting ads. Maybe a good idea?

Author:  hvz [ Wed Jul 11, 2018 6:06 pm ]
Post subject:  Re: Stereo Tool 9.00

Quote:
I've set up the AF frequency in the dialog "AF", and monitored the Command Log Windows for what command is being sent to the UECP port.
But it's not 90.9, it should be 92.7 which is 34 in MagicRDS.

Or you should make a command available to the StereoTool GUI to disable AF with a special command to interrupt the AF's while broadcasting ads. Maybe a good idea?
No, that's just not how the standard works - if you only do it during ads, chances are that receivers will still switch (and many even completely ignore AF method A and just look at PI codes anyway).

I have no idea where 34 comes from. Can you check what 87.6 is?

Author:  PatrickvdHoek [ Wed Jul 11, 2018 7:36 pm ]
Post subject:  Re: Stereo Tool 9.00

87.6 = 01 (AFCH=01)

Raw log:
Code:
<2018-07-11 19:35:28> AF=A
<2018-07-11 19:35:28> AFCH=01
<2018-07-11 19:35:29> CT=0
<2018-07-11 19:35:29> PHASE=0
<2018-07-11 19:35:29> TATMOUT=0
<2018-07-11 19:35:29> EXTSYNC=1
<2018-07-11 19:35:30> ECC=00
<2018-07-11 19:35:30> LIC=00
<2018-07-11 19:35:30> ECCEN=0
<2018-07-11 19:35:31> DI=15
<2018-07-11 19:35:31> *AFCH
<2018-07-11 19:35:31> *DI
<2018-07-11 19:35:31> *PHASE
<2018-07-11 19:35:32> *EXTSYNC
<2018-07-11 19:35:32> *ECC
<2018-07-11 19:35:32> *LIC
<2018-07-11 19:35:32> *ECCEN
<2018-07-11 19:35:33> *CT
<2018-07-11 19:35:33> *UECP
<2018-07-11 19:35:33> *TATMOUT
<2018-07-11 19:35:33> *LTO
Edit: our two transmitters have different PI Codes, just to avoid that the tuners will flip between the two frequencies during Ad breaks. Or is there a better solution to fix all of this?

Author:  hvz [ Wed Jul 11, 2018 8:23 pm ]
Post subject:  Re: Stereo Tool 9.00

Ahhhhhh!!! 34 is a hex number. 34h = 52. See, that's the problem with ASCII mode, it's not clearly defined what's what. Meaning: someone else could easily be using decimal numbers.

There is a better way, but it's complex, the 2nd digit of the PI code together with AF method B should be used to tell receivers when they can or cannot switch.

Author:  PatrickvdHoek [ Wed Jul 11, 2018 8:41 pm ]
Post subject:  Re: Stereo Tool 9.00

92.7 is 52 and 9 is 88.4 FM. Confusing haha...

Some kind of 'ASCII Command mapping' Window inside of StereoTool would be amazing. That way you can let everybody work with the ASCII Mode without making different functions inside your own code when you discover an other piece of software!

This advice is free ;-) Haha.

Edit: now I also get why the PTY in RDS Spy was on 'Weather' instead of 'Pop Music'. Changed PTY to 0A instead of '10'

Attachments:
Screen Shot 2018-07-11 at 8.59.57 PM.png
Screen Shot 2018-07-11 at 8.59.57 PM.png [ 74.03 KiB | Viewed 3563 times ]

Author:  hvz [ Wed Jul 11, 2018 10:12 pm ]
Post subject:  Re: Stereo Tool 9.00

Ok. "Small" problem then: Other programs DO use decimal numbers and they use the same command. And some might use a mix. Ugh. So how do I support both??? Without adding yet another selection, that nobody will know what to set to :(

(By the way, Windows "calc" can do these conversions!)


Edit: For now I'll just add an ASCII (MagicRDS) selection to the list. Which treats any number as hex. That's an easy fix for now.
Edit 2: Hm. Ok. The current code doesn't really make sense. For PTY, I was already expecting hex numbers. For AF I was expecting decimal numbers. Checking now what MagicRDS does.....
Edit 3: Ah. AFCH= seems to be MagicRDS specific (I googled "AFCH=" "RDS" and everything I find points to MagicRDS). So it's pretty easy to convert that to hex without any side effects.

Edit 4: Ugh. This makes no sense. MagicRDS sends the PTY code as a decimal number (and for some reason I was reading it as hex, not sure anymore why I did that...), but AF is apparently sent as hex. Greeeeeeat..... :(


Ok. So. This is a bit weird.

First, AF method A. I think I'm correctly supporting that now. (the next build will support hex numbers for AFCH=).

Then AF method B. I've tried the following: Set frequencies 87.7 (02), 87.8 (03), 87.9 (04) as AF's with the same content as our actual signal at 87.6 (01). Set 88.4 (09), 88.5 (0A) and 88.6 (0B) as regional variants.

Here's what MagicRDS sends me:
Code:
AF=A
AFCH=01,01,02,01,03,01,04,09,01,0A,01,0B,01
AF=1
AFCH=
AF=2
AF=B
That first line AF=A, makes no sense at all.
The 2nd line shows pairs: 01, 01/02, 01/03, 01/04, 09/01, 0A/01, 0B/01. 01 is our own frequency, the ones where 01 is first are identical, the ones where 01 the last on the list are regional variants (it's a bit more complex than this but in this case this is true).
Then, AF=1. Why?
AFCH= - an empty list - why??
AF=2 - why?
AF=B - makes sense, but why send AF=A first? Besides, for the RDS encoder itself it makes no difference, all it needs to do is send the list on the 2nd line. But NOT the empty list.

So, I'm not really sure what's happening here and what the extra lines mean. They will cause the current code to fail, because the 2nd line will be parsed after the first one and will clear the whole list.

This is what you get for method A:
Code:
AF=A
AFCH=01,02,03,09,0A,0B
Which makes perfect sense and works. Anyone any idea what's happening here?

(MagicRDS was written to talk to Pira's own RDS encoder, so it's basically a propriatory format)

Final edit: MagicRDS doesn't support more than 12 AF frequencies for method B. I could basically ONLY accept AFCH after AF=A, but without understanding what I'm doing that sounds like a bad idea...

Page 18 of 29 All times are UTC+01:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/