under linux even as a command line utility
64 bit linux distros which most of us use these days
Calling the new alpha ('r128gain-1.0-alpha-1-win32-native') directly from the commandline gives the Windows error popup:[blockquote]'r128gain.exe hat ein Problem festgestellt und muss beendet werden.' (encountered a problem and has to be closed.)AppName: r128gain.exe AppVer: 0.0.0.0 ModName: msvcrt.dllModVer: 7.0.2600.5512 Offset: 0000ee96[/blockquote]Example commandline:r128gain.exe --helpr128gain.exe "C:\tmp\02.wav"Simply running 'r128gain.exe' will start the GUI, subsequent processing works fine then. I'm using WindowsXP SP3 32bit.
Error loading SoX
Hi,I don't know if it's the good place to post, but it's the only forum I have found about r128gain.I have just updated my sox version to 14.4.0 but it seems that now the r128gain encoder is no longer working, printing me this error :Code: [Select]Error loading SoXI'm on a 64bits Ubuntu using the cli version, what can I do to solve this problem.I would like to precise that before I updated SoX it was working well.ThxDarkflames0
At start-up R128GAIN tries to load "libsox.so" from the (sub-)folder "r128gain-tools". The error message "Error loading SoX" is generated in case loading "libsox.so" fails.
Quote from: pbelkner on 19 June, 2012, 02:05:17 AMAt start-up R128GAIN tries to load "libsox.so" from the (sub-)folder "r128gain-tools". The error message "Error loading SoX" is generated in case loading "libsox.so" fails.On Debian-based systems, several format handlers are separate modules that are loaded by libsox. I'd guess there might be a version mismatch between those modules (probably now updated to 14.4.0) and this local libsox.so that pbelkner mentions.
I've uploaded a modified lib1770 and posted some details about it [a href='index.php?act=findpost&pid=803753']here[/a]. It may be useful if you ever get around to implementing a multi-threaded scanner. It also makes it possible to compile the library with MSVC, by guarding some C99 code and providing C89 alternatives. I hope Microsoft decides to adopt C99 some day, though. I didn't include the full distribution or the Makefiles, but I did throw in a MSVC 2010 project file.
Queue and cache files sequentially, and work on them in parallel as each file is done getting cached.
The point is that it adds a lot of complexity to the program. But it's not obvious to me whether it really contributes to the program's over all performance. [...] Maybe ther're some measurements available comparing parallel vs. sequential implementations in order to justify whether adding much complexity to the program is really worthwhile.
See this, for instance.
It leverages multi-core CPUs with lots of RAM by copying input files to a tmpfs mount, and running multiple processes concurrently (one per file and per codec).
Ok, I understand that you are an expert for such kinds of programs.
Is it worthwhile to add the complexity to a program when it is not obvious how many people will really profit from it?
Any chance you would add command line options for setting Sox & FFmpeg to different folders...than the assumed default.--path-sox--path-ffmpegI'd just like to only have one copy of each on my system is all.Thanks for your time and all your effort.
I've uploaded a modified lib1770 and posted some details about it [a href='index.php?act=findpost&pid=803753']here[/a]. It may be useful if you ever get around to implementing a multi-threaded scanner. It also makes it possible to compile the library with MSVC, by guarding some C99 code and providing C89 alternatives. I hope Microsoft decides to adopt C99 some day, though.
- bs1770_nd_t *rp=rp+ctx->size;+ bs1770_nd_t *rp=mp+ctx->size;
You made a typo on line 85 of bs1770_ctx.c:Code: [Select]- bs1770_nd_t *rp=rp+ctx->size;+ bs1770_nd_t *rp=mp+ctx->size;
There is no R128-1 and R128-2.
... Moreover, this expands the potential use of this tool to much larger territories such as the USA, because the US standard (ATSC A/85) at the moment uses ITU BS.1770. So, a European user would use R128 and have gated measurement (as it is now, with 10LU relative gate and an absolute gate). A US user would use ITU BS.1770 and have no relative gate (only -70LUFS absolute gate) as this is what's valid for their territory.
ATSC A/85 does not mandate any specific version of BS-1770. It actually says "Users should utilize the current version of BS-1770 for measurements". This has resulted in some confusion as to whether gated measurement techniques should be used - but those in the broadcasting leading the efforts in this field are very clear that gated measurements as introduced in BS1770-2 should be used. I have heard that an update to ATSC A/85 is likely to be published shortly and expect this topic will be clarified.