Author Topic: Encoding at full speed  (Read 616 times)

Hanuman

  • Posts: 58
Re: Encoding at full speed
« Reply #25 on: 16 Jun '22 - 23:46 »
The BASS.NET version works... in a VM. It's annoying that it only works on Windows due to a useless dependency on WinForms.

It was failing to compile because I omitted the solution project. I've re-created the project in a solution here.

If you get issues with the Bass/BassEnc projects, just remove them from the .csproj file and put the BASS DLLs in the output folder manually.

Ian @ un4seen

  • Administrator
  • Posts: 24494
Re: Encoding at full speed
« Reply #26 on: 17 Jun '22 - 13:13 »
Unfortunately, I'm still getting errors when trying to use your updated test project in MonoDevelop (v7.8.4) here - it says "NuGet packages need to be restored before building". I've never used NuGet, so I'm not sure what that means, but I tried the "Restore NuGet Packages" option on the "NuGet" folder and got an "Invalid restore input. Invalid target framework 'unsupported'" error.

Anyway, just to be clear, I'm running these tests on Linux, as I think you were only having problems on Linux? But it sounds like you ran the BASS.Net test in a Windows VM? Is that because it won't run on Linux, and if so, which dll(s) from the BASS.Net package did you try? I tried the standard/core/v4.5/Linux DLLs in my BASS.Net version of your test and all worked.

Hanuman

  • Posts: 58
Re: Encoding at full speed
« Reply #27 on: 22 Jun '22 - 21:03 »
What version of .NET do you have installed? Ah it's the MONO framework probably... not .NET Core. What is Target Framework set at for your project?

Using Bass.NetWrapper v2.4.12.5 throws this in Linux. Indeed, System.Windows.Forms is Windows-only. Might run in MONO though.

Quote
The type initializer for 'Un4seen.Bass.Bass' threw an exception.
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.

Bass.Native is a bit more recent but doesn't support .NET Core.

Running the sample with ManagedBass I gave you on Windows throws:

Quote
System.StackOverflowException
  HResult=0x800703E9
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>

This clearly says that the StackOverflow occurs in unmanaged code (C++) as it cannot evaluate the call stack.

If you could get BASS.NET working in MONO, you should be able to run ManagedBass also in MONO?
« Last Edit: 22 Jun '22 - 21:23 by Hanuman »

Ian @ un4seen

  • Administrator
  • Posts: 24494
Re: Encoding at full speed
« Reply #28 on: 23 Jun '22 - 15:38 »
Ah yes, after creating a new project that uses ManagedBass, I was able to reproduce the problem. I looked into it and found the issue is that there are 2 EncodeStart methods that match your call; one uses BASS_Encode_Start and the other uses BASS_Encode_StartUser. In this case, it's using BASS_Encode_StartUser (with proc=null), which isn't what you want, and it's resulting in recursive file writing calls in BASSenc (you'll notice the output file get very big) before the stack eventually overflows. I've reported the issue to one of the ManagedBass maintainers. I will also add a proc=null check in BASS_Encode_StartUser, as it's an invalid setting.

In the meantime, you can use "CommandLine: destination" in your EncodeStart call to force the correct overload.

Hanuman

  • Posts: 58
Re: Encoding at full speed
« Reply #29 on: 23 Jun '22 - 17:39 »
I confirm, simply adding "CommandLine: " before "destination" to switch overload solves the problem.

Related ticket on the ManagedBass side.
« Last Edit: 23 Jun '22 - 17:46 by Hanuman »