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. |
9th July 2017, 17:32 | #3541 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user. And, for what introduce a problem when is clear in AviSynth docs? "Audio is always converted to Float" Point.
__________________
BeHappy, AviSynth audio transcoder. |
|
9th July 2017, 20:56 | #3542 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
The output behavior isn't something AviSynth+ did, all I did was point out that OPT_AllowFloatAudio and the downconvert were not absolute. If I had my druthers, we'd do away with OPT_AllowFloatAudio entirely so that ACM behavior matches direct library access. In 2017 most programs should not have issues taking Float audio, and in the rare case one does, that should be the user's responsibility to make the script comply with it, not make the correct behavior an opt-in because some vague notion of undisclosed program names 10 years ago maybe couldn't handle Float audio. Direct library access is the proper and preferred method to use AviSynth (explicitly so for AviSynth+, but classic AviSynth had been moving in that direction for years). It's not a bug that direct library access has only ever output the final processed format rather than forcing a downconversion. The docs not being clear about that isn't AviSynth+'s fault. |
|
10th July 2017, 07:35 | #3543 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?
http://avisynth.nl/index.php/Amplify "8bit and 24bit audio is converted to float; the other audio formats are kept as they are." Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back? When it comes to audio bit depth, I'm not sure I'd care about converting to a higher bitdepth automatically. You don't lose quality, and a higher bit depth output generally wouldn't be a problem. If the output is being converted to a lossy format and float is acceptable, (why is LAME still limited to 24 bit?) the user gets to be ignorant of no harm having been done. If AVS did convert to float when a filter needed it, there's a possibility user intervention would be being required at the output stage rather than prior to the filter, but if it doesn't, user intervention is required each time a similar filter is used. . Automatically converting video from one type to another is one thing, but I'm not sure converting "type" and converting "bit depth" necessarily have to follow the same rules. If I was ruler of the world, the law would require the same bit depth in and out when there's no processing involved, and float when there is, as all filters would be required to accept float. How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage? Last edited by hello_hello; 10th July 2017 at 07:37. |
10th July 2017, 15:22 | #3544 | Link | |||
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
Quote:
Quote:
|
|||
10th July 2017, 16:36 | #3546 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Not the I use the 16 bit hack much, but I thought that was the main point of it. On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise? Thanks. |
|
11th July 2017, 02:38 | #3547 | Link | ||
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
There's also the question of how much CPU and memory all of that would eat and whether whatever benefit you do end up seeing is worth it, or whether keeping it all in the same bit depth is faster for the same general perceptual quality (and a lot of that is naturally subjective). Quote:
If there's no obvious difference in quality, whichever is faster. If neither is distinctly faster, use what the encoder you're giving it to supports. Regarding the encoder part, if you're dealing with something like ffmpeg, ffmpeg as a command line program is distinct from the libavcodec encoders you'd be feeding the stream to. For instance, with MP3: LAME supports multiple formats including 16-bit integer, 32-bit integer, and float, whereas libshine only supports 16-bit integer. So optimally, even though ffmpeg has no problems opening float audio (and will perform the conversion prior to handing it to the encoder), if you wanted to encode with libshine, it would be more streamlined to output 16-bit int from AviSynth, so ffmpeg wouldn't have to convert it first. But if you were going to use LAME, you could use any of the three formats it allows. Thanks. Last edited by qyot27; 11th July 2017 at 02:43. |
||
11th July 2017, 08:05 | #3548 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
qyot27,
Thanks for the info. Previously when I asked why LAME is still limited to 24 bit, I appear to have put myself in the completely wrong category. When foobar2000 creates a LAME encoder preset itself, it sets 24 as the maximum input bit depth, and I would've bet copious amounts of money I'd tested that, but I tried setting the maximum input bitdepth to 32 (which I assume is always float for foobar2000) and had no problem encoding with LAME. I'll have to ask about it in the foobar2000 forum. (Edit: I asked and apparently 32 bit float support was added to LAME with version 3.99) Thanks for the info regarding high bitdepth processing of 8 bitdepth video. As processing in 16 bit is very slow using my old PC and I'd not seen much visible benefit compared to 8 bit, or realistically any benefit at all most of the time, I've not bothered filtering in 16 bit. I'd assumed "technically" it'd still be better, even if in practice it often appears not to be. So I guess "preventing clipping" would be the only remaining argument for always converting audio to float for processing, especially when multiple filters are daisy-chained. I assume that's why foobar2000 always converts to float when a DSP is used, which seems reasonable (at least that's my understanding). I'd be close to admitting I was wrong when it comes to the implicit vs explicit conversion of bit depth, except for the possibility of clipping avoidance. To my way of thinking if converting to float prevents it, it should be prevented, and if a filter is capable of inducing clipping, processing the audio in anything but float seems like a bad idea, and therefore accepting anything but float as the input would also be less good. It doesn't eliminate the need for checking for clipping at the output stage, but at least you don't have to worry about it until then. Cheers. Last edited by hello_hello; 12th July 2017 at 07:20. |
11th July 2017, 09:01 | #3549 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
Precission of float 32 values is equivalent (more or less) to 24 bit int because 32 float have 24 bits for mantissa (+ 8 for exponent). Downsample to 16 bits int lose precission, and the average human ear can distinguish up to 20-bit differences. Math operations must be do always in float format to preserve precission even with low values. Int maths: (3/2)x2 = 2 float maths: (3.0/2.0)x2.0= 3.0
__________________
BeHappy, AviSynth audio transcoder. Last edited by tebasuna51; 11th July 2017 at 09:30. Reason: Add info |
|
11th July 2017, 10:25 | #3550 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
Anyway, Levels was among the first filters that was ported and the code is probably a bit messy and not finished (float support). Nor did I benchmark that a safety check on over-10-bits garbage before applying LUT (and thus allowing smaller 10 bit LUT tables) has any significant effect on execution time. Sure, Levels is on my todo list. |
|
18th July 2017, 20:55 | #3551 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
Just out of curiousity, if this okay to ask here - as a quick straw poll, which would people prefer vis a vis Avisynth+: existing plugins updated to x64, or existing plugins updated to handle the new colourspaces?
Last edited by wonkey_monkey; 18th July 2017 at 21:14. |
19th July 2017, 18:55 | #3555 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
At least judging by the changes made to AviSynth+ itself in order to work on 64-bit, doing so would generally make the code more portable and easier to maintain, which is always a good thing. All the new pixel formats are much more purpose-oriented, and adding them after doing the work to make the plugins 64-bit compatible would be more efficient.
|
22nd July 2017, 14:41 | #3556 | Link | |
Registered User
Join Date: Jun 2016
Posts: 9
|
Quote:
I have a problem, could you please help me solve it? When ever I try to install any Avisynth + other than version r1576 i get this error message http://imgur.com/1xkIhGL I tried to locate the folder, but it didn't work even when I installed r2294 I got the same error! |
|
22nd July 2017, 14:48 | #3557 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Do you possibly mix up 64 bit DLL and 32 bit system folder? Which Windows version do you have? Which file manager do you use? (If it's anything else than Windows Explorer: A 32-bit version of a custom file manager won't have access to the 64-bit system area.) In general: More facts! More details! More quotes of error messages!
P.S.: I guess it's time to build a recent installer again. Moving DLL's manually into sensitive areas is not everyone's favourite challenge. The Avisynth Universal Installer (run "as Administrator") would be a helpful alternative; unfortunately you have to edit it correctly to maintain plugin paths, or possibly copy all your plugins around, so it's not really straightforward and easy-to-use either for people with less experience. Handling paths with spaces and even parentheses is tricky in Batch. Last edited by LigH; 22nd July 2017 at 14:58. |
22nd July 2017, 15:00 | #3558 | Link | |
Registered User
Join Date: Jun 2016
Posts: 9
|
Quote:
Even with a normal installer by Groucho2004 which I got from here: http://avisynth.nl/index.php/Avisynthplus/Downloads won't work only r1576 works. I'm on windows server 2012 64-bit and I'm using windows explorer. |
|
22nd July 2017, 15:10 | #3559 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Then, next steps: download and unpack AVSMeter, and check
|
22nd July 2017, 15:39 | #3560 | Link | |
Registered User
Join Date: Jun 2016
Posts: 9
|
Quote:
Thank you so much LigH, I updated the Microsoft Visual C++ Runtime and it worked. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|