search

lordmulder / LameXP

Audio Encoder Front-End
http://lordmulder.github.io/LameXP
Other
184 stars 18 forks source link

wav conversion to ogg: sample rate problem #26

Closed foggyxp closed 8 years ago

foggyxp commented 8 years ago

Conversion of a wav-file of a cd-ripping 44.1 kHz to an ogg-file with a sample rate of 32 kHz doesn't work; only conversion to 44.1 kHz is possible. (LameXP v4.11 and v4.12, windows 7 pro). As much as i remember it worked before. On mobile players 32 kHz-files (mp3 and ogg) sound much better than 44.1 kHz. That's why i need to downsample. (conversion to mp3 there is no problem with any sample rate)

lordmulder commented 8 years ago

There seems to be a bug with resampling in OggEnc2 v2.87. I just noticed that a new version of OggEnc2 is available now, which claims to have fixed the "resampling bug". I'll update OggEnc2 soon.

BTW: According to Nyquist–Shannon sampling theorem, the max. frequency that can be retained is 1/2 the sampling rate. So by going down from a sampling rate of 44.1 kHz to a sampling rate of 32 kHz, you are effectively low-pass filtering the signal. In other words, you throw away the highest frequencies. So you probably want to adjust the EQ setting on your playback device rather than mangling the audio file.

lordmulder commented 8 years ago

Okay, please tray with this test build: LameXP-TEST.2015-10-26.Release.Build-1825.7z

foggyxp commented 8 years ago

Thank you 2015-10-26.Release.Build-1825.7z: resampling to 32 kHz ogg-file works well. While the programm is runnig, the LameXP Debug Console-Window stays open.

xtemp09 commented 8 years ago

Why do developers not use g++ when linking it against Qt?

I just realized if it were compilable with g++, people would download it and compile it easily, since there are a lot of small gcc bundles and building environments, instead of downloading the entire Visual Studio.

lordmulder commented 8 years ago

@foggyxp: It's a pre-release build, that's why. Use --no-console, if you want to hide the console. Or just ignore it.

@xtemp09: LameXP is developed in Visual Studio (Visual C++), so cannot link it again the MinGW version of Qt. Mixing pure C code from different compiles is possible to a certain degree, but mixing C++ code from different C++ compiles is not possible. Heck, if you want to use the "official" MinGW builds of MinGW you even have to use the exactly same MinGW version/flavor that the Qt guys used to make their binaries.

If you mean we should make it possible to build LameXP completely under MinGW/MSYS, maybe I will implement this one day. But at the moment I don't have any concrete plans. If you ever tried to make a complex C++ project build under MSVC and MinGW, you know the #ifdef nightmare that will be required. Heck, there's even a zillion of different MinGW packages floating around on the net that are highly incompatible. I've got more than enough things on my "todo" list that are more fun than this :wink:

xtemp09 commented 8 years ago

I meant those ones that are listed in "Downloads" on qt-project.

Qt is bundled with Qt Creator+gcc. When I was creating screenshots in one of the issues, I opened the project in Qt Creator and even compiled it, but it required manual involvement in compilation process and code analysis.

lordmulder commented 8 years ago

If you want to link LameXP with the "official" pre-compiled Qt libraries for MinGW, then you have to build the entire application (which also includes all the third-party libraries!) with MinGW/GCC!

Currently, LameXP is built using Visual Studio, which can not use the MinGW compiler. Consequently, we would have to switch the build system from a Visual Studio Project (MSBuild) to either a Qt Creator Project or a GNU Makefile. And that not only for LameXP itself, but also for all third-party libraries. That alone would be a big amount of work! But, as experience shows, C/C++ code written for Visual Studio won't compile under MinGW/GCC (and vice versa!) without additional tweaks. And if you which to maintain compatibility with both, MinGW/GCC and MSVC, your code will be cluttered with #ifdef hackery...