StaxRip

[stax76]

M stands for mod, it shows the estimated file size in the status line.

[ACKR]

Originally Posted by stax76

M stands for mod, it shows the estimated file size in the status line.

ah thanks

[JKyle]

AviSynth+ 3.6.1 is released.

[Arkana]

Hi, I'm always getting this error when converting audio to AAC on latest version

----------------------- Error Audio encoding 2 -----------------------

Audio encoding 2 returned error exit code: -1073741701 (0xC000007B)


-------------------------- Audio encoding 2 --------------------------

eac3to 3.34

D:\Apps\StaxRip-x64-2.1.1.7-beta\Apps\Audio\eac3to\eac3to.exe "D:\JD DL\Crawl.2019_temp\Crawl.2019 ID1 English.ac3" "D:\JD DL\Crawl.2019_temp\Crawl.2019 ID1 English_a2.m4a" -quality=0.4 -normalize -progressnumbers


-------------------------- Audio encoding 2 --------------------------

eac3to 3.34

D:\Apps\StaxRip-x64-2.1.1.7-beta\Apps\Audio\eac3to\eac3to.exe "D:\JD DL\Crawl.2019_temp\Crawl.2019. ID1 English.ac3" "D:\JD DL\Crawl.2019_temp\Crawl.2019 ID1 English_a2.m4a" -quality=0.4 -normalize -progressnumbers

Start: 6:35:51 PM
End: 6:35:51 PM
Duration: 00:00:00

any idea why and how to solve it?

[jlw_4049]

Originally Posted by Arkana

Hi, I'm always getting this error when converting audio to AAC on latest version




any idea why and how to solve it?

Try to use ffmpeg decode/encode

Sent from my SM-G986U1 using Tapatalk

[Patman]

Originally Posted by Arkana

Hi, I'm always getting this error when converting audio to AAC on latest version




any idea why and how to solve it?

neroAacEnc.exe is in eac3to folder?

EDIT:

I've updated some tools:

aomenc, ffmpeg (normal) and ffmpeg (libnpp_enabled), MP4Box, npp64_11 (from new cuda sdk), QTfiles64, rav1e and SVT-AV1EncApp

[JKyle]

Originally Posted by Patman

I've updated some tools:

aomenc, ffmpeg (normal) and ffmpeg (libnpp_enabled), MP4Box, npp64_11 (from new cuda sdk), QTfiles64, rav1e and SVT-AV1EncApp

Many thanks.

It seems like ffmpeg (libnpp_enabled) has a dependency problem with libnpp library files.
I have no return from the executables.

Other binary files seem to be OK although I tested ffmpeg (normal), MP4Box, npp64_11, QTfiles64 only.

[JKyle]

qaac is updated to 2.69.

It seems OK except that the new version still fails to encode a flac file demuxed by mkvextract from an mkv file, which is an issue that needs to be addressed by mkvextract.

[stax76]

It seems OK except that the new version still fails to encode a flac file demuxed by mkvextract from an mkv file, which is an issue that needs to be addressed by mkvextract.

Maybe this here relates:

https://gitlab.com/mbunkus/mkvtoolni...-not-supported

[Patman]

Originally Posted by JKyle

Many thanks.



It seems like ffmpeg (libnpp_enabled) has a dependency problem with libnpp library files.

I have no return from the executables.

You need the npp files from npp64_11_v*.zip to use these version or use the npp64_11_v*.exe (extract the files to right folder). Pls test and give me a feedback.

[stax76]

@Patman

There is an issue with your SVT-AV1EncApp build not sending the same output as the official build, it causes staxrip not showing correct progress with your build, it works with the official build. Please note that my system don't use the western code page 1252 but rather UTF8.

[Patman]

Originally Posted by stax76

@Patman

There is an issue with your SVT-AV1EncApp build not sending the same output as the official build, it causes staxrip not showing correct progress with your build, it works with the official build. Please note that my system don't use the western code page 1252 but rather UTF8.

I've found the reason, building with gcc is the problem. I've uploaded a static version (without shared lib) compiled with msvc1926 (vs).

[stax76]

I created an issue on their tracker, I think it's not because of text encoding but rather flush timing, somehow different console implementation of the compiler.

[JKyle]

Originally Posted by Patman

You need the npp files from npp64_11_v*.zip to use these version or use the npp64_11_v*.exe (extract the files to right folder). Pls test and give me a feedback.

I verified that ffmpeg.exe/ffprobe.exe work OK if npp*.dll files in npp64_11_v2.7z are placed in the same folder as the executables.

That said, I'm wondering if this npp enabled ffmpeg will be able to provide any marginal benefit over NVEnc considering how handy and versatile it is to use NVEnc instead. NVEnc comes with more encoding options and hardware filters than ffmpeg, and in my experience, the result is almost always more satisfactory than ffmpeg. But of course npp enabled ffmpeg can become handy in a situation where ffmpeg should be run on its own.

BTW, is including fdk-aac in a distributed ffmpeg static build still against license? Well, since the native aac encoder in ffmpeg is still kind of mediocre, I think fdk-aac has a competitive edge in creating HE-AAC and HE-AACv2 so it's worth giving a try. But of course ignore it if it violates the license.

[JKyle]

Originally Posted by stax76

Maybe this here relates:

https://gitlab.com/mbunkus/mkvtoolni...-not-supported

It's sad news.

Anyway, thanks for the pointer.

[JKyle]

This is a very trivial typo but since it's still there even in the latest beta (2.1.3.2), I'm putting it down here.

The Default VapourSynth Profiles line 68:

Dither | Gamma / Linear = clip = $select:Gamma To Linear|Dither.gamma_to_linear|Linear To Gamma|Dither.linear_to_gamma$(clip, curve='$select:msg:Select the Color Curve;601;709;2020$')

There, Dither.gamma_to_linear and Linear To Gamma should be separated by a semi-colon(;) not by a pipe(|).

[Patman]

Originally Posted by JKyle

BTW, is including fdk-aac in a distributed ffmpeg static build still against license?

Yeah, that's the reason why you can't find a ffmpeg with fdk-aac enabled.

EDIT:

I successfully build a x264 version with direct avs and vpy input (will upload later). My test build of x265 (not available yet) works with direct avs input and now I want to implement support for direct vpy input. I hope it works ;-)

EDIT2:

@stax76 pls update QSVEnc (4.04) and VCEEnc (6.02)

[JKyle]

Originally Posted by Patman

I successfully build a x264 version with direct avs and vpy input.

I downloaded your new vpy-enabled x264(x264M-0.160.3009-4c9b076-gcc11.0.0.7z) and tested it with the following vpy input (resize and HDR to SDR).

import os, sys
import vapoursynth as vs
core = vs.get_core()
sys.path.append(r"D:\Utilities\StaxRip\Apps\Plugins\VS\Scripts")
core.std.LoadPlugin(r"D:\Utilities\StaxRip\Apps\Plugins\VS\fmtconv\fmtconv.dll", altsearchpath=True)
core.std.LoadPlugin(r"D:\Utilities\StaxRip\Apps\Support\DGDecNV\DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r"D:\Work\tmp\tst\LG_New_York_HDR_UHD_4K_Demo.OriginalHDR10_temp\LG_New_York_HDR_UHD_4K_Demo.OriginalHDR10.dgi")
clip = core.resize.Spline64(clip, 1280, 720)
clip = core.fmtc.bitdepth(clip, bits=16)
core.std.LoadPlugin(r"D:\Utilities\StaxRip\Apps\Plugins\Dual\DGHDRtoSDR\DGHDRtoSDR.dll")
clip = core.dghdrtosdr.DGHDRtoSDR(clip, mode="pq", white=2600)
clip.set_output()

(I bypassed vspipe.exe by manually putting the x264 encoding command line in the Command Prompt.)

It works perfectly with direct vpy input and furthermore, gives a little gain in encoding speed over vspipe.exe in this test.

<Pipelining via vspipe.exe>
encoded 1806 frames, 37.77 fps, 4718.12 kb/s

<Direct x264 encoding>
encoded 1806 frames, 38.19 fps, 4717.61 kb/s

I guess StaxRip can now get rid of vspipe.exe when it comes to x264 encoding with your new x264 build.



#BTW, it would be helpful if the zipped filename is differentiated from your previous x264 builds.

[stax76]

Direct script input is a great feature not only for staxrip.

I changed the x264/x265 description in the apps dialog adding:

Patman mod shows the estimated size in the status line.

Remind me if I later forget to also add the avs/vpy support to the description.

If x265 supports avs input then it's necessary to generate an avisynth.dll soft link next to x265 in order to use the portable avisynth.dll instead of the installed one. Next build will do this.

I'll probably leave avs2pipemod the default however for increased compatibility, otherwise people not knowing the piping tool selection option would get an error if they replace the build with one that does not support script input.

[Patman]

Originally Posted by JKyle

#BTW, it would be helpful if the zipped filename is differentiated from your previous x264 builds.

THX for testing all further version have vpy-input enabled, so the filename is the same. I hope it's okay