Cannot build source on windows

[v1r]

Hi there,
I have problems building the library using cmake on windows due to dependencies.. is there any binary out there for windows already built...

Thanks!

[chrisn]

Hi Karim,

We don't have Windows binaries available, sorry. This is something I'd really like to see but haven't the time to do it yet.

Cheers,

Chris

[v1r]

Hi Chris,

I'll try to build it in windows and I'll back to you when done.

[v1r]

Tried but encountered many compiling errors..

[chrislatina]

I did also plan to use this on windows. A build tutorial would be great -- installation for OSX was very straightforward. I'll will take a look into this further and document any issues that arise.

[sunilit42]

any news for window?

[thom4parisot]

@chrislatina @sunilit42 hello :-) well we provided build instructions on Mac because we had access to such a machine. Sadly we don't have anybody with a Windows OS in the office.

Could you eventually share your compiling errors @v1r?

A good alternative would be to use Docker to run the Linux compiled version on Windows.

[pedro-veiga]

Hello and a big "Thank You" to BBC Research and Development for your great tools :-)
Sorry to be asking again, are there any news of a working Windows build?
Cheers!

[chrisn]

No real news yet, sorry. I tried to set up a build using Visual Studio, but there was a lot of work to do to get all the library dependencies built correctly. Maybe cross-compiling using mingw would be easier? If time allows, I do plan to continue working on this.

[annonymous45]

would love to see the windows version working too

[kbengine]

would love to see the windows version working too

[phinett]

this would be perfect if i could run on windows too.

[nahuelhds]

+1 here

[zg4455]

+1

[smohammedyasin]

did any one find the way to run in windows? please response.

[pedro-veiga]

So, this is not quite the same as a native Windows build we all wished for, but since Windows10 and the release of "Windows Subsystem for Linux" there is a way around this problem.
After taking some time to configure and study the WSL environment, it is indeed possible to build Audiowaveform for Linux on Windows, or any other Linux command line tools for that matter!
Then they run seamlessly from a normal Windows command prompt. It's quite impressive actually, all things considered.
It still presents some challenges though, for example the file paths as arguments might not work as expected.

[smohammedyasin]

so there will be no window binary? we must use alternate way to run current library on windows:(
i have windows hosting with .net mvc applicaiton. and i think will be very challenging part to run on it

[onlyet]

I wanna debug this project in windows using Visual Studio, it's inconvenient without windows binary ,maybe we could choose FFmpeg? Hope to get out earlier.

[awaisnova]

did any one find the way to run in windows? please response.

[hlthi]

I compiled audiowaveform in Windows successfully.
(msys2 mingw-64 , newer boost lib 1.66.0 , no mp3 support)

But :/

I have not found the right way to compile Libid3tag for Windows . As a result ,this program need some preprocessing before use mp3. Other types works perfectly.

audiowaveform -i test.mp3 -o test.dat -z 256 -b 8

sox test.mp3 test.wav
audiowaveform -i test.mp3 -o test.dat -z 256 -b 8

I want to ask a question @chrisn before share...

  #optionhandler.cpp   
 
  Mp3AudioFileReader reader;

    if (!reader.open(input_filename.string().c_str())) {
        return false;
    }

    WavFileWriter writer(output_filename.string().c_str());

    return reader.run(writer);

is same thing as logical with

sox in.mp3 out.wav 

[chrisn]

@hlthi Great news, thank you! I'm still hoping to produce a native Windows build using Visual Studio, but my time to work on this is limited. Your effort is much appreciated.

You're right, the code you quoted simply converts audio from MP3 to WAV format.

[hlthi]

@chrisn ,
I've fixed the mp3 issue, but I have to ask to be sure.

Mp3AudioFileReader::skipId3Tags's last line

fseek(file_, sizeTag, SEEK_SET)

Is the only valid for id3v2 ?

ID3v2 -> before the audio data
ID3v1 -> after the audio data

You skip id3tag in Mp3AudioFileReader::open method but this is only valid for ID3v2. Is that correct ?

[chrisn]

Yes, the idea of that code is to skip ID3v2 tags at the beginning of the file. This was the cause of an earlier bug, see #34.

Do you have a working build of libid3tag for Windows now?

[hlthi]

Thanks @chrisn .

No :/ But I searched 0xFFF or 0xFFE for dedect start of mp3(11111111111 pattern MPEG Audio Frame Header). It is same as skip tag for id3v2.

Libid3tag was only used with that function, so I do not need it anymore.

[chrisn]

I was hoping that the Windows build wouldn't require too many code changes, what's the issue with building libid3tag?

[hlthi]

Ohh, orginal build doesn't handle id3V1 tag and same out of sync error #34.

I hope these could help you,

Working after v1.1.0

Not working now

It can need change

#Mp3AudioFileReader::run method

#clear id3v1 tag from last bytes , before this line or something else???
BStdFile bstd_file(file_);   

[hlthi]

Libid3tag windows error same as -> Bug Debian

[hlthi]

https://github.com/hlthi/audiowaveform-windows/releases Readyy !

I did not do enough testing, I need some sleep.

[sergeevabc]

@hlthi, it asks for missing libboost_filesystem-mt.dll.

[wincentbalin]

Hello Chris,

I was able to compile static Windows binaries of audiowaveform using MXE, both 32-bit and 64-bit. I put the compilation script as well as the source code patch into this gist.

Shall I fork this repo and create the pull request with the patch applied?

[chrisn]

@wincentbalin Looks great, thank you! A couple of points: I wonder if we can avoid patching the source code (e.g, the boost::filesystem::path change)? Also, a statically linked build is something other people have asked for, see #35. Maybe we can add a BUILD_STATIC flag so that the CMakeLists.txt file finds and brings in the additional libraries and set the relevant build flags. I'll set up MXE and try your script.

[wincentbalin]

Additionally, I found other way to compile static binaries for Windows. I used Ubuntu with MinGW64 in Docker; the results are in this repository.
Also, I put the binaries both for win32 and for win64 onto the Releases page in that repository.

Regarding the patch: indeed, we could just add the calls to the string() method without #ifdefs, because on POSIX it just returns the internal representation of the path (whereas on Windows it converts the wstring-path to string). To be honest, I did not test resulting binaires with corner cases, for example when filenames contain umlauts (äüöß).

[sergeevabc]

Tested @wincentbalin's x64 build, works as expected, thanks!

Why don’t you output manual (--help) by default? It’s quite short.
Vertical axis for dB scale (currently missing) could be useful (captured in Ocenaudio editor).

[chrisn]

@wincentbalin I'm still waiting for MXE to build, it takes a while :-) So, what I'm thinking is we can:

• Fix the use of boost:filesystem::path so we don't need to use conditional compilation
• Modify CMakeLists.txt to enable static builds, for all platforms
• Add a simplified version of your build script to the project, possibly also with the Dockerfile to make it easy set up MXE

[chrisn]

@sergeevabc This issue is about building audiowaveform on Windows. Please, would you mind raising separate issues for your other suggestions.

[wincentbalin]

@chrisn I do not have much experience with CMake, but fixing usage of boost::filesystem::path is easy. Shall I clone your repository, apply the fixes and make a pull request?

[chrisn]

Yes, please do. I'll take a look at CMakeLists.txt based on your modifications.

[wincentbalin]

I forgot to mention that the MXE compilation script can be considerably sped up if you set the environment variable JOBS to the number of CPU cores, for example

JOBS=4 ./audiowaveform-compile.sh

on a quad-core CPU.

[wincentbalin]

Just tested input and output filenames with non-ASCII characters, and they work.

[chrisn]

@wincentbalin Thanks for testing. I was wondering whether we'd need to change the command line option handling to use wchar_t on Windows, and use wchar_t functions when opening files. I can do that in the future, if needed.

I'm currently looking at enabling static builds on Linux, will report progress in #35.

[balagangadharanr]

Any update for Windows ?

[wincentbalin]

Look at https://github.com/wincentbalin/compile-static-audiowaveform

[chrisn]

I have now added Windows binaries to the Releases page, thanks to @wincentbalin's great work.

[sergeevabc]

@chrisn, it’s still difficult to create audioform out of the box.
Even following the tutorial makes half-happy with the result.

$ audiowaveform -i test.mp3 -o test.dat --split-channels
Input file: test.mp3
Format: Audio MPEG layer III stream
Bit rate: 128000 kbit/s
CRC: no
Mode: joint (MS/intensity) stereo
Emphasis: no
Sample rate: 44100 Hz
Encoding delay: 1105
Padding: 1611
Generating waveform data...
Samples per pixel: 256
Input channels: 2
Output channels: 2
Done: 100%
Recoverable frame level error: lost synchronization       <--- another scary thing 
                                                               that goes w/o explanation
Frames decoded: 301 (0:07.862)
Generated 1351 points
Output file: test.dat
Resolution: 16 bits
Channels: 2
Done

$ audiowaveform -i test.dat -o test.png
Input file: test.dat             
Channels: 2                      
Sample rate: 44100 Hz            
Bits: 16                         
Samples per pixel: 256           
Length: 1351 points              
Image dimensions: 800x250 pixels 
Channels: 2                      
Sample rate: 44100 Hz            
Samples per pixel: 256           
Start time: 0 seconds            
Start index: 0                   
Buffer size: 1351                
Axis labels: yes                 
Amplitude scale: 1               
Output file: test.png            
Done

Now let’s see…

Err… Where is the rest? A few seconds are obviously missing.

[chrisn]

Recoverable frame level error: lost synchronization

This is normal, it comes from the MP3 decoder when it runs out of data at the end of the file. Seeing lots of these would indicate a problem, such as a corrupted MP3 file.

Err… Where is the rest? A few seconds are obviously missing.

You can either increase the image width, or use the --zoom auto option.

[sergeevabc]

@chrisn, consider making --zoom auto a default, or at least mention it within --help output

$ audioform --help | grep zoom
  -z [ --zoom ] arg (=256)        zoom level (samples per pixel)  
  --pixels-per-second arg (=100)  zoom level (pixels per second)