Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th May 2023, 17:16   #1401  |  Link
gispos
Registered User
 
Join Date: Oct 2018
Location: Germany
Posts: 996
Quote:
Originally Posted by Emulgator View Post
P.S. Tested AvsPmod x86 2.7.4.6 Prerelease 11 on the same WinXP32ProSP3.
The following settings work:
Play video -> Play audio unticked, Audio scrubbing ticked: Play works, Scrubbing works.
What stalls:
The moment I tick Play audio and press Play: Stall after like 10 frames, culprit as above.
There are two x86 audio test versions. Try it.

This is my last try for now, if I have time and ... and find my old XP, I can install it in a VM. But I don't know if it behaves in a VM like a normal install.

https://drive.google.com/drive/folde...usp=drive_link

Edit:
A little tip about audio scrubbing.
If the audio drop outs with the right arrow key, set the scrub count to 3.
__________________
Live and let live

Last edited by gispos; 24th May 2023 at 17:27.
gispos is offline   Reply With Quote
Old 24th May 2023, 23:06   #1402  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Both versions show different behaviour, address_buf is a success.
This was with a 426x238 .mp4 clip 412frames long, 2CH 44,1k 32bpS after FFAudioSource filter decoding

address_buf: Playing with audio preview from the start stalls at frame 11, same culprit.
Go to any frame and press Play: plays 10 frames, 11th frame stall.
But: Pre-scrub just once from start to minimum 50% AND BACK (in my case 212 frames)
and it will play video & audio fine from every position, without stalling.

cast_buf: Playing with audio preview from the start stalls at frame 4, same culprit.
Go to any frame and press Play: plays 3 frames, 4th frame stall.
Pre-Scrubbing won't help here.

Checking back to Prerelease 11: pre-scrubbing won't help there.

That is fine for my corner case. I was already happy with scrubbing audio...
Many thanks for your continued efforts, gispos. Donation how ?

P.S. Later it became instable, pre-scrubbing did not help anymore. Hm.
Well, still better than nothing.

P.P.S. Ah, I was repeatedly reloading a stalled session which started at frame 89.
Now I started clean, moved slider back to frame 0, closed session and reopened:
All was fine now, pre-scrubbing helped.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 24th May 2023 at 23:23.
Emulgator is offline   Reply With Quote
Old 25th May 2023, 20:49   #1403  |  Link
gispos
Registered User
 
Join Date: Oct 2018
Location: Germany
Posts: 996
Quote:
Originally Posted by Emulgator View Post
Both versions show different behaviour, address_buf is a success.
This was with a 426x238 .mp4 clip 412frames long, 2CH 44,1k 32bpS after FFAudioSource filter decoding
One more try
https://drive.google.com/drive/folde...usp=drive_link

Please answer me the following:
1.) Audio scrubbing (count 1) always works?
2.) Audio scrubbing (count 48) plays the audio of all 48 video frames?
3.) Playback in threads is as fast or faster than without threads (Options > 'Accessing AviSynth in threads' and Video > Play video > 'Playback in threads' off.

How fast is the playback with threads (tell me the dimensions and color formats of the video).
__________________
Live and let live
gispos is offline   Reply With Quote
Old 25th May 2023, 22:27   #1404  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by gispos View Post
FranceBB does not give any feedback
Yeah, I know, if anyone wonders why, this is why: Img1


Anyway I'm better now, so tomorrow I'll make further tests, but the behaviour Emulator was seeing with the last version I tested (i.e scrubbing works, right arrow works, but play button with audio crashes after a few frames) is the same I was experiencing. Now that there is a new version, though, I'll repeat the tests too.

Last edited by FranceBB; 25th May 2023 at 22:31.
FranceBB is offline   Reply With Quote
Old 26th May 2023, 01:18   #1405  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
The .mp4 clip:
test2 was stalling after 4 frames, just as cast_buf.
Lets drop that clip, it was borked anyway.
Maybe worth a hint in docs that some odd clip might require that small effort of pre-scrubbing...
-----------------------
Now to a proper DV-AVI 720x576x25i capture from TV:
test 2 stalled just once after heavy scrubbing and playing.
address_buf was better:
stable, not a single stall, playback possible from any position without pre-scrubbing.

Answers
1: Yes, all 3 version do audio scrub 1 frame
2: Yes, all 3 version do audio scrub 48 frames
3: Depends on script, I guess.
------------------------------
Back to address_buf:
Only FFvideo/FFaudio sourcefilters, no processing.
"Normal speed" This played in realtime, well almost, 22..24fps insead of 25.

Added QTGMC (EdiMode="nnedi2")
Video-> Playback in threads ticked: 5,45fps 70% CPU, audio scrubs framewise as expected.
Video-> Playback in threads unticked : 5,45fps 70% CPU, audio muted.
"Access AviSynth in threads" made no difference.
This was without Prefetch.

Playback Prefetch (2,2) helps speed a bit: 6fps, 75..80% CPU and delivers double scrubbed audio.
Playback Prefetch (4,12) kills AvsPmod, well this is too much anyway for 3GB RAM and a 7600G CPU.

Ah well, I guess I should test playback without processing, but in "Maximum Speed".
Playback in Threads unticked : 96fps, Audio muted
Playback in Threads ticked : 92fps, Audio scrubs/skips as expected
Playback in Threads ticked Audio scrub unticked: 92fps, Audio ffwds as expected
The last combo with QTGMC and Prefetch (2,2) 5.8fps/80%CPU
The last combo with QTGMC, Audio scrub and Prefetch (2,2) the same 5.8fps/80%CPU.

Beautiful, what a luxury !
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 26th May 2023 at 01:40.
Emulgator is offline   Reply With Quote
Old 26th May 2023, 07:55   #1406  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Ok, so, I tested test2 as well.

Input source 1:

720x576 25i BT601 TFF yv12 8bit planar source with PCM 24bit stereo 48'000Hz audio muxed in mxf

Audio scrubbing with scrub count to 48 works.
Moving back and forth across the content works and I can hear the audio.
Going frame by frame with the arrow works and I can hear the audio.

Playback without the audio works just fine in realtime.
Playback with the audio also works just fine in realtime for SD contents with CPU being used at around 30% (file indexed with ffms2).
I played it with the play button after turning on the "Play audio" and it just... worked, this time.
I watched 5 minutes of content from minute 25 to minute 30 of a 40+ minutes content and it just... worked.
I jumped to minute 38, played it and, again, it worked.

I don't know what you have done, Gispos, but XP is now singing loud and clear.
What a great surprise I found after recovering from the fever.



EDIT: Arg. Not so fast. When I jumped to 38, it played for 2 minutes to 40:24.159 before showing the error message "the instruction at 0x70869b2b referenced memory at 0x040cc01c. The memory could not be read. Still, this is yet another improvement and a major step forward.

Last edited by FranceBB; 26th May 2023 at 07:57.
FranceBB is offline   Reply With Quote
Old 27th May 2023, 19:16   #1407  |  Link
gispos
Registered User
 
Join Date: Oct 2018
Location: Germany
Posts: 996
AvsPmod 2.7.4.6 final
Code:
* Play Thread revised:
- under WinXP the frames were played 2-3 frames slower than the intended fps for the video (I hope fixed).
- under Win10 64bit the maximum fps is about 10% higher on my system (FHD no filter). 
* Video > Display, 3 menu items added.
- 'Prefetch RGB display conversion' and 'Fast YUV420 display conversion' and ' - fast YUV auto reset'
- Prefetch RGB display conversion: uses Prefetch(2,2) for the default (precise) RGB32 conversion (I recommend to turn it on, default).
- Fast YUV420 display conversion: function 'DecodeYUVtoRGB' must exist (DecodeYUVtoRGB.dll) and CPU instructions AVX2 available.
- if DecodeYUVtoRGB used, prefetch is disabled. So both can always be switched on.
- the fast YUV decode will be always disable if: Preview Filter used or on clip refresh the option ' - fast YUV auto reset' enabled.
- if function DecodeYUVtoRGB not found, the function is loaded from AvsPmod dir if the Dll exist.
* Added CPU AVX2 availability check. If not, fast YUV decoding is disabled. Also disabled on x86 (no x86 DLL).
- Big thanks to DTL and all contributors for this plugin. Also pinterf will improve the precise YUV to RGB32 conversion. Thanks.
* Bugfix: Split View can get error on insert new tab and the video dimensions mismatch.
* Bugfix of Bugfix: Fullscreen mode, if video dimensions equal to monitor dimensions.
* Improved error handling for some conditions.
Hope it runs well under WinXP.
I think the problem with the too low fps is fixed, and I couldn't get any crashes anymore, even with the wildest movements with the slider during playback (but x64).

@Emulgator, 'Audio scrub count' is also not pre-playing but post-playing of the audio and has nothing to do with the playback,
no matter what you set there it doesn't change anything in the audio playback.

@FranceBB, good improvement of health for you and thank you for the feedback.
__________________
Live and let live
gispos is offline   Reply With Quote
Old 27th May 2023, 23:40   #1408  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Thank you Gispos, as always!

It still occasionally leads to the error on XP when audio playback is on and I click play, but still.
As far as performances are concerned, definitely an improvement as I was able to play a FULL HD file at 47fps on XP.
FranceBB is offline   Reply With Quote
Old 28th May 2023, 18:00   #1409  |  Link
gispos
Registered User
 
Join Date: Oct 2018
Location: Germany
Posts: 996
Quote:
Originally Posted by FranceBB View Post
Thank you Gispos, as always!

It still occasionally leads to the error on XP when audio playback is on and I click play, but still.
As far as performances are concerned, definitely an improvement as I was able to play a FULL HD file at 47fps on XP.
Too bad that it does not work with WinXP. @Emulgator do you have problems as well?

Uploaded a Pre-Release x86 before, don't think it helps.... but who knows.
It checks the read audio buffer for its size. Maybe a 32bit system is more sensitive.

https://drive.google.com/drive/folde...usp=drive_link

Edit:
Quote:
Originally Posted by FranceBB View Post
I was able to play a FULL HD file at 47fps on XP.
If not already set, then add the option: Video > Display > 'Prefetch RGB display conversion'.
__________________
Live and let live

Last edited by gispos; 28th May 2023 at 18:28.
gispos is offline   Reply With Quote
Old 28th May 2023, 20:08   #1410  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Not yet, I have yet to return to that XP system.
Travelling with 2x Win10Pro64 atm.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."
Emulgator is offline   Reply With Quote
Old 29th May 2023, 07:48   #1411  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by gispos View Post
Uploaded a Pre-Release x86 before, don't think it helps.... but who knows.
It checks the read audio buffer for its size. Maybe a 32bit system is more sensitive.
Thanks, I just tested it, but it didn't help...



Quote:
Originally Posted by gispos View Post
If not already set, then add the option: Video > Display > 'Prefetch RGB display conversion'.
49.93fps out of 50p without audio, 49.80fps out of 50p with audio. Close enough, I'd say.
Definitely an improvement from 4-5 tests ago when it was nowhere close.


Quote:
Originally Posted by gispos View Post
Too bad that it does not work with WinXP.
I really don't understand. Audio scrubbing works like a charm.
Seeking with my right key works like a charm too.
But if and only if I click "Play" it outputs this after a while: https://i.imgur.com/3RJs76C.png

it makes no sense...
Any other ideas?
FranceBB is offline   Reply With Quote
Old 29th May 2023, 08:15   #1412  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
"Also disabled on x86 (no x86 DLL)."

New fixed build now have also x86_32 .dll - https://forum.doom9.org/showthread.p...04#post1987704 . Also the errors in conversion to RGB are now decreased. So the fastest AVX2 engine with 16bit immediate processing now produce residual errors close to natural quantization noise of 8bit samples of YUV.

Also it may be useful for PC-monitor (not supporting professional narrow range with superwhites displaying) script output preview add modes for 'unclipped superwhites' monitoring. With new DecodeYUVtoRGB it is with proc-amp setting of gain=69, offset=0. With standard ConvertToRGB32() using PC-matrix you got and raised blacks and degraded contrast and also required additional Levels() tweak for correct RGB decoding - https://forum.doom9.org/showthread.p...08#post1987708

So with internal AVS core filters the unclipped superwhites monitoring it is something like

*for YUV source*
Levels(0,1,255,16,235) // to workaround RGB decoding witjh PC-matrices
ConvertToRGB32(matrix=PC...) // to keep superwhites in output
Levels(16,1,255, 0,255) // to put black from 16 to zero to keep contrast

Also it was found 'external plugins' with YUV to RGB decoding like avsresize and fmtc provide a bit better precision narrow RGB range at RGB 8bit output (less average error) and not require Levels() pre-hacking (so should run faster at large frame sizes).

Last edited by DTL; 29th May 2023 at 10:44.
DTL is offline   Reply With Quote
Old 29th May 2023, 11:58   #1413  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
Levels(0,1,255,16,235) // to workaround RGB decoding witjh PC-matrices
Is that supposed to be as default Levels(..., coring=True), ?

EDIT: I think that RGB 'narrow range' is sometimes known as "Studio RGB".

EDIT: Hmm, no mention of "Studio RGB" for a few years, then PoisonDeathRay mentions it,
and then a few hours later I again mention it.

PDR says:
Quote:
There was an old dedicated "studio RGB" function by "trevlac" for avisynth
here:- https://forum.doom9.org/showthread.p...08#post1987708
I could not remember 'trevlac' as source of that discussion,
thanx PDR.

EDIT: And it seems FranceBB regularly mentions "Studio RGB" as being one of his favourite things.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 29th May 2023 at 12:28.
StainlessS is offline   Reply With Quote
Old 29th May 2023, 12:11   #1414  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by StainlessS View Post
I think that RGB 'narrow range' is sometimes known as "Studio RGB".
It is and it's honestly one of the things I had to work with in broadcast due to the fact that you can't carry full range signals via SDI cables 'cause you need bits reserved to timecode and other things.

Needless to say, I hate it to the very core 'cause literally the whole world assumes RGB to be Full PC Range and in Studio RGB (which is limited) there are no metadata whatsoever, so the whole infrastructure needs to be aware of it from start to end, otherwise bad things happen.
FranceBB is offline   Reply With Quote
Old 29th May 2023, 13:13   #1415  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
"Is that supposed to be as default Levels(..., coring=True), ?"

As I see from wiki - coring is looks like also some old days hacking/workarounding (to make any good working of lots of different plugins and also VirtualDub plugins) and it may also somehow work with old AVS core Convert(). http://avisynth.nl/index.php/Levels . May be even PC-matrix for Convert() was adapted to work only with 'double-narrow' YUV. And it was not put to public documentation.
But newer external plugins (avsresize and fmtc) can process standard YUV narrow into RGB narrow without any additional hacks and with better precision. Also saving from additional full frame RAM scan and additional precision lost on integer processing.

"RGB 'narrow range' is sometimes known as "Studio RGB"."

May be. Also there are many different words for 16..235 nominal range mapping (shifted black from zero and non-clipped nominal white) - limited, narrow, Studio and may be others. The latest EBU documents of end of 201x and 202x use 'narrow' word as I see.

Like https://tech.ebu.ch/news/2020/05/ebu...ignals-and-hdr
The first publication, EBU R 103 v3.0 – Video Signal Tolerance in Digital Television Systems, addresses confusion regarding the use of different video ranges. The most important one involves distinguishing between 'full' and 'narrow' range video.

" whole world assumes RGB to be Full PC Range"

It may be in PC world only. May be good for still imaging like photos with sRGB and MS Word. But as some googling shows the endusers market with game consoles already provide limited RGB and also HDMI have metadata signalling about full or limited RGB. Also for HTPC solutions users may sometime output 4:4:4 RGB in limited range to display device. So limited RGB already known in endusers homes too when dealing with motion pictures and gaming. So for avspmod software display interfacing may be implemented all possible modes - narrow/limited RGB, full RGB, zero black partially narrow range for non-clipping superwhites (16..255 to 0..255 mapping).

Not very old PC display adapters can be also switched between full and narrow/limited range in RGB via some digital connection (HDMI/DP) - https://pcmonitors.info/articles/cor...-and-amd-gpus/ . So user may monitor moving pictures most close to professional video monitor without superwhites clipping (if display tuned/calibrated correctly).

One more idea if it still not implemented to solve PC and motion pictures levels and other displaying (spatial scaling):
For pro level NLE the GUI displayed at standard PC monitors and for best moving pictures master monitoring separate special hardware output to 'video' master monitor is used (SDI when possible like Blackmagic simple SDI output adapter or HDMI or even simple other/secondary monitor). For home use it can be simulated with HDMI output to some TV-set or other 'video' type display. So from Windows software it may require separation of 'video' window from main application window so user can move it to expanded desktop area to other (HDMI for example) 'video' display. Or the application may remember its position or try to draw this window at 'other hardware display' - not primary for example. And user can configure that 'video' control display to use narrow/limited RGB (or YUV in future ?) and keep standard PC RGB levels at application GUI primary display.

2 main difference exist between 'PC' display and 'moving pictures' display:
1. PC typically use full RGB levels with zero black and peak white may be nominal white and use max code value and 'moving pictures' display uses narrow/limited levels with raised black (allow some super blacks or undershoots) and non-max code value nominal white (allow some superwhites or data overshoots).
2. PC typically use direct samples to display pixels mapping with no any scale operation (can display pixel art without distortions) and 'moving pictures' display receive spatially encoded/compressed (contigous image) data and use some system scaler to display upsampled image at its pixel screen (can not display pixel art without distortions).

So because 1 and 2 are significantly different display types for digital data input - it is better to have physically 2 separate monitors for application GUI and Windows interface and 'moting pictures' master monitoring.

Also with some software computing the PC display can be used as 'moving pictures' master monitor but levels re-mapping required (black to zero and max superwhites to max display code value) and in best case correct system upscale (at least 2x if possible).

Last edited by DTL; 29th May 2023 at 20:43.
DTL is offline   Reply With Quote
Old 30th May 2023, 19:03   #1416  |  Link
gispos
Registered User
 
Join Date: Oct 2018
Location: Germany
Posts: 996
Quote:
Originally Posted by DTL View Post
"Also disabled on x86 (no x86 DLL)."

New fixed build now have also x86_32 .dll - https://forum.doom9.org/showthread.p...04#post1987704 . Also the errors in conversion to RGB are now decreased. So the fastest AVX2 engine with 16bit immediate processing now produce residual errors close to natural quantization noise of 8bit samples of YUV.
Thanks! will use it in the next version.
Am curious, have not tried it yet. Will report back.

Quote:
Originally Posted by FranceBB View Post
it makes no sense...
Any other ideas?
Playback and scrubbing pass the audio data to different routines.

The whole thing runs through PortAudio via a Python wrapper.
There are two ways to write the data, writing is correct, because it is written to the output stream.

Scrubbing uses the direct write to stream method, I put the whole thing in a thread so that the video frame fetch is not blocked.
The direct writing requires more effort, but for me it was easier to implement the code and test the audio in the beginning.

In the playback a callback function from PortAudio or the wrapper is used. PortAudio fetches the provided audio data itself in this routine.
The advantage: I only have to care about reading the audio data and providing it. This also brings speed advantages in the playback, I don't really trust the Python threads, they mostly behave differently than one is used to from other programming languages.

But apparently there are problems with 32bit in this callback routine.

Here I have a version that uses your own thread for audio playback. I am full of hope.
Not tested much but runs under x64.
https://drive.google.com/drive/folde...usp=drive_link

And I also have something to say about the slower fps (Emulgator):
I had changed that in the last version, don't know if that helped with Emulgator's fps, FranceBB apparently had no problems with it.

Anyway, I have undone the changes. The reason is my stupidity (forgetfulness?), at that time I had sat for days on the playback thread until it ran satisfactorily.
The problem is the timing:
Windows has an accuracy of about 10-20 ms, but this is not enough, so the system timer is increased for the duration of the playback. If the used OS and hardware can't do this to 1 ms, everything runs a bit slower.
According to Microsoft, the performance timer is available from Win 2000, so if it runs slower with XP, then XP or the hardware is to blame.

I tried a loop, which is stupid because it also increases the CPU load. Therefore I have undone this.

The displayed fps are also only average values. It is the read frames with the past time calculated, and with several hundred frames then already deviations can arise.

@FranceBB I only want to read good things
__________________
Live and let live
gispos is offline   Reply With Quote
Old 31st May 2023, 05:07   #1417  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by StainlessS View Post
Is that supposed to be as default Levels(..., coring=True), ?
It's supposed to be coring = False, nice catch . Limiting or clipping values is separate step
poisondeathray is offline   Reply With Quote
Old 31st May 2023, 09:11   #1418  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by gispos View Post
apparently there are problems with 32bit in this callback routine.

Here I have a version that uses your own thread for audio playback. I am full of hope.

@FranceBB I only want to read good things
You wanted to hear only good things and let me tell ya: you got it!
This version works like a charm, including with the playback.
I played a content for 8 minutes and 39 seconds without a break and it just kept going and going with no issue.
I also moved ahead and started playing again and it worked. No problems at all.

- No errors accessing memory
- No crackling sound
- Jumping back and forth worked
- Standard playback worked
- Scrubbing worked
- peak FPS 49.94fps on some 50p contents and 49.81fps on some more complex contents


Sweet. Very sweet, considering that this is probably the best x86 can do.

Awesome, Gispos, awesome.
FranceBB is offline   Reply With Quote
Old 31st May 2023, 17:09   #1419  |  Link
gispos
Registered User
 
Join Date: Oct 2018
Location: Germany
Posts: 996
Quote:
Originally Posted by FranceBB View Post
You wanted to hear only good things and let me tell ya: you got it!
This version works like a charm, including with the playback.
I am still waiting for a 'EDIT: Arg. Not so fast.'

Glad that it works.
__________________
Live and let live
gispos is offline   Reply With Quote
Old 31st May 2023, 17:31   #1420  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
@FaBB, More ass kissing required. [EDIT: Use your tongue, he like that]
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 31st May 2023 at 17:35.
StainlessS is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.