FujiConvert 0.1

[+CharlieChaplin]

Well,

 

I would suggest to 1) either use different file extensions for mono / stereo (but nothing else), e.g. *.PDM = mono and *.PDS = stereo or alternatively 2) use a header that tells the player all required information, i.e. not only mono/stereo, but also linear and non-linear values, DC Offset, Coarse Levels, Fine Levels, Bump settings, etc.

 

Guess the different file extension (PDM/PDS) is the simplest thing to change in the available players by FJC and Xuel, whereas implementing the header (and then appropriate playback) requires much more work...?!? Of course one could also use different file extensions for PCM (simply *.PCM), PWM (*.PWM) and Covox (e.g. *.COV and since that sounds/looks like Covid, maybe *.CVX) then...?!?

 

If one prefers a header, then the authors of the players (FJC and Xuel) should co-operate and reach an agreement regarding what numbers, values and other information should be used in that header and how the sound should be played back then (and the header should be fully documented then)...

 

[flashjazzcat]

Completely agree. Anything with a header should have a different extension to the existing formats. Likewise, I was already thinking that *.PDS would be an ideal extension for stereo files in the absence of metadata.

 

Metadata leaves the way open for future implementations which can perhaps act on some of the granular settings, or at the very least display detailed file information in the player.

 

[Mathy]

Hello guys

 

As long as you don't call it .PMS...

 

But on a more serious note: Would it make sense to have files converted for Quad Pokey?  .PDQ?

 

Sincerely

 

Mathy

 

PS yes, please come up with a new format for these FujiConverted files which include a header.  But please leave some room for extra data we might want in there in the future.  Maybe the loader/player/cartmenu could show the relevant data in that header.

 

 

[flashjazzcat]

17 minutes ago, Mathy said:

As long as you don't call it .PMS...

Already rejected.

17 minutes ago, Mathy said:

Would it make sense to have files converted for Quad Pokey?

Bitrate would be very low (it halves for each additional channel). Stereo is already 22KHz.

18 minutes ago, Mathy said:

But please leave some room for extra data we might want in there in the future.  Maybe the loader/player/cartmenu could show the relevant data in that header.

Wholly agreed.

[Mathy]

Hello Jon

 

9 hours ago, flashjazzcat said:

Bitrate would be very low (it halves for each additional channel). Stereo is already 22KHz.

 

Isn't it like: It halves each time the channels get doubled?  As in: Mono = 44 kHz, Stereo = 22 kHz and Quad Pokey = 11 kHz?

 

11 kHz might be enough for certain sound(effect)s.

 

Would it be possible to run halve the channels in halve the frequency of the other halve?  As in: 2 x 7 kHz + 2 x 14 kHz?  Where the sound of the lower frequency channels are only changed half as much as those of the higher frequency?

 

Not sure if that's ever gonna be useful, just asking...

 

Sincerely

 

Mathy

 

[Faicuai]

On 4/24/2021 at 8:23 PM, Faicuai said:

will be re-mastering all .PDMs with 5/7 for non-linear pulse and 4/6 for linear pulse, FYI (this is based on last minute tests I conducted on PDM-TEST utility).

 

Oh, wow!!! NEVER thought I would discover Pokey's world of "digital-vinyl" records !! This is SOO COOOL !! ??

 

Anyhow, worked for quite a while on these tracks, and here are my final .PDM re-masters, from where I can no longer extract any further (discernable) quality improvement.  These were encoded / tested as this:

 

1. Parameters: 2048, NO Auto-Gain, PDM, NTSC, MONO, 44Khz, Levels (16,16,0 - YES, back to 16!), Non-linear P.: 5-7; Linear P.: 4-6, IDE
2. Tested sound output on / over:
   • Atari 800 / Incognito / Sophia-2 (1983, final USA production run).
   • Over RF-interface Audio-out (which remains fully operational) and MONITOR-port Audio-out
   • 5w Logitech, $10 shitty PC speakers (bias to mid-range)
   • 1000w, 5.1 Logitech sound system (Atari 800 => DVDO iScan Vp50pro, HDMI video+audio out to TV, TV=>Logitech Sound processor, via Optical), with bias to low and high range. 
3. Best performing tracks (get ready to blow your friends' socks with these ones) ?
   • Two Hearts (Phil Collins)
   • Price of Love (New Order)
   • Just Like Heaven (The Cure)
   • Welcome (NAMCO Sounds, Galaga Legions DX)
   • End Titles (TRON Legacy)
   • 19 (Paul Hardcastle) => My older son turned 19 earlier this year, and I sent it to him, as a reminder of being grateful in life...
4. Most challenging tracks (really hard on the encoder / playback / POKEY, we simply need a higher sampling bit-rate) ?
   • Son of Flynn (Tron Legacy)
   • Solar Sailer (Tron Legacy)
   • Come Undone (Duran Duran)
   • Major Tom (Shiny Toy guns)

Here are al of the above, attached in a single .ZIP file:  FujiConvert - pdm16 (5_7_4_6) mono 44610Hz IDE ntsc.zip

 

As a side note, running the player with DMA=OFF is not only a necessity from a procedural point of view, but also from a sound-quality point of view. The 800's noise-floor (over RF or monitor-port out) drops substantially when suspending ANTIC DMA operation, as well as keeping GTIA activity to a minimum !!!

 

 

Edited April 28, 2021 by Faicuai

[flashjazzcat]

7 minutes ago, Faicuai said:

As a side note, running the player with DMA=OFF is not only a necessity from a procedural point of view, but also from a sound-quality point of view.

If you're talking about the IDE player, you do realise the player disables playfield DMA regardless?  Constant bitrate playback would otherwise be impossible.

[Faicuai]

13 minutes ago, flashjazzcat said:

If you're talking about the IDE player, you do realise the player disables playfield DMA regardless?  Constant bitrate playback would otherwise be impossible.

Absolutely.

 

And THANKS God it does so (not just for procedural needs, as mentioned before). Otherwise, we get a shitty noise=floor with ANTIC DMA-on.

Edited April 28, 2021 by Faicuai

[flashjazzcat]

I'm just curious: what's the difference between the 'procedural needs' and the sound quality?

[Faicuai]

3 minutes ago, flashjazzcat said:

I'm just curious: what's the difference between the 'procedural needs' and the sound quality?

The need for every bit of CPU power to run the player, PLUS bringing down the noise-floor. A combined effect (& benefit).

 

Then you run this over a high-power audio system, you start hearing clearly... 8-)

Edited April 28, 2021 by Faicuai

[flashjazzcat]

6 minutes ago, Faicuai said:

The need for every bit of CPU power to run the player, PLUS bringing down the noise-floor. A combined effect (& benefit).

The sound quality is more an overriding objective than a 'benefit'. It is the express reason for disabling playfield DMA fetches, since we are trying to write to two POKEY registers every 37 machine cycles. If the CPU is constantly halted by DMA fetches, it'll sound like shit whether you listen through a high-power audio system or not.

 

Edited April 28, 2021 by flashjazzcat

[Faicuai]

12 minutes ago, flashjazzcat said:

it'll sound like shit whether you listen through a high-power audio system or not.

Not exactly.

 

Do this test (with no particular sound being played through Pokey):

 

1. Grab any of your A8's and connect it to an (good quality) amplified audio-system.
2. Go to (say) BIOS, disable key-sound, and raise volume (listen).
3. Launch basic and poke 559,0. Also raise volume (and listen / compare).
4. Launch a GTIA rainbow-test (with Antic DMA off). Listen / compare.

 

You will be surprised. This is completely aside from whatever the player needs or does.

Edited April 28, 2021 by Faicuai

[flashjazzcat]

Sadly I'm a peasant and don't have a good quality amplified sound system, so can't tell the difference. I'll take your word for it, though.

 

[Faicuai]

6 minutes ago, flashjazzcat said:

Sadly I'm a peasant and don't have a good quality amplified sound system, so can't tell the difference. I'll take your word for it, though.

 

Any will do, as long as it does not add or introduce higher levels of noise (that's what "high quality" meant...)

 

A TV with good integrated speakers (and volume raised high enough) should do, as well.

Edited April 28, 2021 by Faicuai

[flashjazzcat]

Wow. I am learning so much here. I knew the built-in speakers in my monitor sucked, but now I know that 'high quality' speakers also exist.

 

[Faicuai]

4 minutes ago, flashjazzcat said:

Wow. I am learning so much here. I knew the built-in speakers in my monitor sucked, but now I know that 'high quality' speakers also exist.

 

Don't despair, though.

 

In the absence of everything, any set of headphones may work, too.

 

 

[+CharlieChaplin]

Well,

 

if I remember correctly the "resampling window" (where you use 2048) is only in effect when converting to 4Bit PCM or PWM, it should have no effect with 8bit PDM ?!? But maybe I am wrong here.

 

So you are using this setup/config. for Fuji Convert:

- Preset: 16-16-0

- DC Offset ??? (ranges from +7 to -8, no clue what value is good here)

- Coarse Levels: 16 ?

- Fine Levels: 16 or 14 ?

- Bump: 0

- Non-Linear Pulse: 5/7

- Linear Pulse: 4/6

- Mono, 44khz (stereo 22khz produces too much noise in my opinion)

- IDE player (FJC or Xuel)

 

I tried DC Offset with a) -7, b) zero and c) +7 but did not notice any difference. (But I am hard hearing / hearing impaired, maybe that is why.) And errmm, since version 0.3.x I always use auto gain, in older versions of Fuji Convert I first converted the songs to WAV format and turned up the volume quite a lot. This is no longer nescessary with auto-gain, so why do you suggest NOT to use auto-gain?

 

Find attached MI by E for IDE player (AVG or SIDE), a) converted with Fuji Convert 0.2.x, no auto-gain, b) with version 0.3.4, auto-gain, DC Offset = -7 and 16 fine levels, c) with version 0.3.4, auto-gain, DC Offset = 0 and 15 fine levels and d) with version 0.3.4, auto-gain, DC Offset= +7 and 14 fine levels. To me there seems to be quite a difference regarding sound quality of a) vs. b), c) and d), but there seems to be no (or very little difference) between versions b), c) or d), so DC Offset and Fine Levels did not matter that much there it seems...?!? All conversions are for PAL machines, since I only own PAL Ataris.

 

 

MI by E mono version 02 no auto gain.zip MI by E version 034 pdm14 mono.zip MI by E version 034 pdm15 mono.zip MI by E version 034 pdm16 mono.zip

[Faicuai]

19 minutes ago, CharlieChaplin said:

Preset: 16-16-0

- DC Offset ??? (ranges from +7 to -8, no clue what value is good here)

- Coarse Levels: 16 ?

- Fine Levels: 16 or 14 ?

- Bump: 0

- Non-Linear Pulse: 5/7

- Linear Pulse: 4/6

- Mono, 44khz (stereo 22khz produces too much noise in my opinion)

- IDE player (FJC or Xuel)

 

In addition to the above:

 

1) Resampling = 2048 because that's how it was set since the beginning of my tests. No changes there.

2) DC Offset: untouched / default value (+7)

3) Fine Levels: set to 16

4) IDE player (FJC) on SIDE-2, plugged on L-Cart. port on 800 / Incognito (Player itself is launched from Incognito's HD).

 

I will try your tracks when I come back to the retro-desk. Going out now.

 

Cheers!

 

Edited April 28, 2021 by Faicuai

[+CharlieChaplin]

3 minutes ago, Faicuai said:

 

In addition to the above:

 

1) Resampling = 2048 because that's how it was set since the beginning of my tests. No changes there.

2) DC Offset: untouched / default value (+7)

3) Fine Levels: set to 16

4) IDE player (FJC) on SIDE-2, plugged on L-Cart. port on 800 / Incognito (Player itself is launched from Incognito's HD).

 

I will try your tracks when I come back to the retro-desk. Going out now.

 

Cheers!

 

 

When I choose 16-16-0 for Preset, then DC Offset default value is -8 (changed the preset to other values and then back again just to make sure that DC Offset always defaults to -8 and yes, it does). For PDM playback I am using Xuel's PDM player on the AVG cart.

 

[Roydea6]

can this player be modified to show different colors other than white and grey.  blue+yellow red+green anything but the dull white+grey.

 

[Faicuai]

1 hour ago, CharlieChaplin said:

When I choose 16-16-0 for Preset, then DC Offset default value is -8

I would like to correct that my default (always) is -7 (minus). My apologies for the "+" (incorrect) above.

 

Furthermore, I have NEVER changed or edited this value. Only the ones I have explicitly mentioned.

 

Have you attempted to play the tracks I posted above? 

[Xuel]

DC offset shifts all sample values by the specified amount. When using 16 fine levels, a value of -8 can help with songs that have quiet sections where the sample values are all near the middle of the dynamic range. The reason is that it shifts these values to be centered in a range of values where only the fine level changes, e.g 112 through 127 or $70 - $7F, instead of centered in a range of values where the bottom half of the values map to one coarse level and the top half map to the next coarse level. You don't want to constantly be moving back and forth between values just below $7F and values just above $80 because the boundaries between coarse level increments are glitchy. So avoiding crossing them reduces noise. This is the similar to the phenomenon that causes the dark line between brightness levels 7 and 8 in GTIA mode 9.

 

DC offset should be set to around -finelevels/2 for maximum benefit for quiet parts. But note that this reduces the available dynamic range and can cause clamping. For consistently loud songs it might be better to set DC offset to 0 to maximize the dynamic range.

[Xuel]

The resampling window size controls the quality of sinc resampling for all output formats and playback methods. Larger values improve the quality but increase conversion time. The only time the window size doesn't matter is if you input a WAV file with exactly the same sample frequency as the output format, i.e "freq" in the constrained settings sections. In this case resampling is skipped.

 

Choosing "None" tells FujiConvert to use a simple nearest neighbor type of conversion between sample rates which is fast but can be noisy/tinny sounding.

 

[Faicuai]

12 hours ago, Xuel said:

The reason is that it shifts these values to be centered in a range of values where only the fine level changes, e.g 112 through 127 or $70 - $7F, instead of centered in a range of values where the bottom half of the values map to one coarse level and the top half map to the next coarse level.

This could be precisely the reason why both TRON-Legacy tracks (especially Solar Sailer) have quite a good deal of trouble with "hissing" and "noise" that can be clearly heard, all over. 

 

I will have to experiment a bit more with these particular tracks. I just wanted a single, common encoding recipe for any track. It may not be the case, though.

 

(NOTE: also, could you check if AUTO-Gain is working correctly on latest encoder version? I pre-analyzed all my test tracks with external SW and noticed max recording levels and clipping. There were tracks that were hitting max. recording levels and a bit of clipping, yet FujiConvert wanted to "auto-gain" +2 on all of them, which did not sound right to me.)

 

 

Edited April 29, 2021 by Faicuai

[ivop]

13 hours ago, Xuel said:

This is the similar to the phenomenon that causes the dark line between brightness levels 7 and 8 in GTIA mode 9.

That phenomenon is also partly due to the four resistor DAC they used. 36k, 18k, 9k1, and 4k7 (with 5% tolerance), which does not match exact powers of two. Based on 4k7, that should be 37k6, 18k8, 9k4, and 4k7. This could be fixed with a proper R2R ladder of 1K and 2K resistors. Faster rise and fall times, too. Or do what UAV and Mytek's video out circuit do. Proper video DAC, with builtin R2R ladder.

 

 

Edited April 29, 2021 by ivop