You can watch introduction video at https://youtu.be/AlRDaNACx3Y.

You can download Windows binaries from Releases (under Assets).

If you have any thoughts or comments about this project, feel free to post them in Discussions.

Shibatch Sample Rate Converter (SSRC) is a fast and high-quality sample rate converter for PCM WAV files. It is designed to efficiently handle the conversion between commonly used sampling rates such as 44.1kHz and 48kHz while ensuring minimal sound quality degradation.

• High-Quality Conversion: Achieves excellent audio quality with minimal artifacts.
• FFT-Based Algorithm: Utilizes a unique FFT-based algorithm for precise and efficient sample rate conversion.
• SleefDFT Integration: Leverages SleefDFT, a product of the SLEEF Project, for fast Fourier transforms (FFT), enabling high-speed conversions.
• SIMD Optimization: Takes advantage of SIMD (Single Instruction, Multiple Data) techniques for accelerated processing. It is capable of high-speed conversion using AVX-512.
• Dithering Functionality: Supports various dithering techniques, including noise shaping based on the absolute threshold of hearing (ATH) curve.
• Specialized Filters: Implements high-order filters to address the challenges of converting between 44.1kHz and 48kHz.
• Selectable Conversion Profile: You can select the filter lengths and computing precision. Single-precision computation is generally sufficient for audio processing, and even the standard profile allows for highly accurate conversion. However, since this tool is designed for audiophiles, you can also select a profile that performs all computation in double precision.
• Low-Latency Real-Time Processing: Suitable for demanding real-time applications by combining minimum-phase filters with an efficient partitioned convolution algorithm.

Sampling rates of 44.1kHz (used in CDs) and 48kHz (used in DVDs) are widely used, but their conversion ratio (147:160) requires highly sophisticated algorithms to maintain quality. SSRC addresses this challenge by using an FFT-based approach, coupled with SleefDFT and SIMD optimization, to achieve a balance between speed and audio fidelity.

See here for some experimental results.

• Operating System: SSRC is compatible with multiple platforms.
• Audio Files: Input files should be in PCM WAV format.

1. Download the latest release from the GitHub repo.
2. Extract the downloaded archive to a directory of your choice.
3. Ensure the ssrc executable is accessible from your command line.

The basic command structure is as follows:

ssrc [options] <source_file.wav> <destination_file.wav>

You can also use standard input and output:

cat input.wav | ssrc --stdin [options] --stdout > output.wav

Convert a WAV file from 44.1kHz to 48kHz with dithering:

ssrc --rate 48000 --dither 0 input.wav output.wav

Profiles allow you to balance between conversion speed and quality (stop-band attenuation and filter length).

You can see all profiles and their technical details by running ssrc --profile help.

The --mixChannels option allows you to mix, re-route, or change the number of channels using a matrix string.

• Syntax: The matrix string is a series of numbers separated by commas (,) and semicolons (;).
  • Commas (,) separate the gain values for each column in a row.
  • Semicolons (;) separate the rows.
• Logic:
  • The number of rows in the matrix defines the number of output channels.
  • The number of columns in the matrix must match the number of input channels.

To combine a 2-channel stereo input into a 1-channel mono output, you can use a 1-row, 2-column matrix. The standard formula is Mono = 0.5 * Left + 0.5 * Right.

--mixChannels '0.5,0.5'

To duplicate a 1-channel mono input into a 2-channel stereo output, you can use a 2-row, 1-column matrix.

--mixChannels '1;1'

This sets both the left and right output channels to be equal to the mono input channel.

To swap the left and right channels of a stereo file, you need a 2x2 matrix. The goal is to make the new left channel equal to the old right channel, and the new right channel equal to the old left channel.

--mixChannels '0,1;1,0'

• The first row 0,1 means Output0 = (0 * Input0) + (1 * Input1).
• The second row 1,0 means Output1 = (1 * Input0) + (0 * Input1).

The project includes scsa, a command-line spectrum analyzer. While it can be used as a general-purpose analyzer, it is primarily designed for automated testing and verification, for example in a CI environment.

• Automated Testing: The primary purpose of scsa is to check audio spectra against predefined criteria, making it ideal for automated quality assurance in a CI/CD pipeline.
• Cross-Platform and Dependency-Free: As a command-line tool, it does not rely on any GUI libraries or have OS-specific dependencies, making it highly portable and easy to integrate into various workflows.
• SVG Output for Debugging: When a test fails, scsa can generate an SVG image of the spectrum. This visual output is extremely useful for identifying the cause of the failure. An SVG is also generated if no check file is provided, allowing scsa to be used as a general-purpose analyzer.
• High-Precision Analysis: Unlike many standard analyzers, all internal processing is performed in double precision. This minimizes the impact of floating-point noise, allowing for highly accurate measurements.
• High-Resolution Windowing: It uses a 7-term Blackman-Harris window function, which provides excellent dynamic range and frequency resolution, enabling very sharp and precise spectrum analysis.

scsa [<options>] <source file name> <first position> <last position> <interval>

The check file is a plain text file that defines the spectral criteria for the scsa tool. Each line in the file specifies a single constraint.

• Format: Each constraint is defined on a new line with the following format: <low_freq> <high_freq> <comparison> <threshold_db>

  • <low_freq>: The lower bound of the frequency range in Hz (double).
  • <high_freq>: The upper bound of the frequency range in Hz (double).
  • <comparison>: The comparison operator. Can be one of < (less than), > (greater than), or ^ (peak).
  • <threshold_db>: The threshold value in decibels (double).

• Comments: Lines starting with a # character are treated as comments and are ignored. Empty lines are also ignored.

• Logic: The check logic depends on the comparison operator:

  • <: Checks if all frequency components in the range are less than the threshold.
  • >: Checks if all frequency components in the range are greater than the threshold.
  • ^: Checks if the peak frequency component in the range is greater than or equal to the threshold.

• Example:

  # This is a comment
  # Check for stop-band attenuation
  1 9900 < -140
  
  # Check for pass-band flatness (hypothetical)
  # 20 20000 > -1
  

  In this example, the tool will check if the spectrum is below -140 dB in the frequency range from 1 Hz to 9900 Hz. The second rule is commented out, so it will be ignored.

In addition to the command-line tool, SSRC provides powerful C++ and C APIs, allowing you to integrate the resampling engine directly into your own projects. It can be built as a static or shared library for native applications on Windows (without requiring MSYS/Cygwin), Linux, and other platforms.

For detailed information on the API, please see API_DOCUMENTATION.md.

A modern, C++17 API that uses templates and standard library features for flexible and type-safe audio processing pipelines.

A C-language API that is compatible with the popular SoX Resampler library (libsoxr). By defining SSRC_LIBSOXR_EMULATION, SSRC can serve as a drop-in replacement for soxr in existing projects.

1. Clone the repository:

   git clone https://github.com/shibatch/ssrc
   cd ssrc

2. Make a separate directory to create an out-of-source build:

   mkdir build && cd build

3. Run cmake to configure the project:

   cmake .. -DCMAKE_INSTALL_PREFIX=../../install

4. Run make to build and install the project:

   make && make install

1. Download and install Visual Studio Community 20XX.

• Choose "Desktop development with C++" option in Workloads pane.
• Choose "Git for Windows" in Individual components pane.
• Choose "C++ Clang Compiler for Windows" in Individual components pane.

2. Create a build directory, launch Developer Command Prompt for VS 20XX and move to the build directory.

3. Clone the repository:

   git clone https://github.com/shibatch/ssrc
   cd ssrc

4. Run the batch file for building with Clang on Windows.

   winbuild-clang.bat -DCMAKE_BUILD_TYPE=Release

5. Copy libomp.dll to the directory where the exe file is located.

This project uses the following third-party library:

• dr_wav: A public domain single-file library for working with .wav files. The library is used in this project for reading and writing WAV files.

• Email: shibatch@users.sourceforge.net

The software is distributed under the Boost Software License, Version 1.0. See accompanying file LICENSE.txt or copy at : http://www.boost.org/LICENSE_1_0.txt. Contributions to this project from individual developers and small organizations are accepted under the same license. For contributions from corporate users, please refer to CONTRIBUTING.md.

We believe that Free and Open Source Software (FOSS) is a wonderful ecosystem that allows anyone to use software freely. However, to maintain and enhance its value over the long term, continuous maintenance and improvement are essential.

Like many FOSS projects, we face the challenge that long-term sustainability is difficult to achieve through the goodwill and efforts of developers alone. While the outputs of open-source projects are incorporated into the products of many companies and their value is rightfully recognized, the developers who create these outputs are not always treated as equal partners in the business world.

A license guarantees the "freedom to use," but the spirit of the FOSS ecosystem is based on a culture of mutual respect and contribution built upon that freedom. We believe that accepting the "value" of a project's output while unilaterally refusing dialogue with its creators simply because they are individuals undermines the sustainability of this ecosystem. Such companies should not turn a blind eye to the reality that someone must bear the costs to make the cycle sustainable.

This issue is not just about corporations; it reflects a deeper cultural expectation within the FOSS ecosystem itself. Over time, we have come to take for granted that everything in open source should be provided for free - not only the code, but also the ongoing effort to maintain and improve it. However, FOSS licenses guarantee the freedom to use and modify software; they do not impose an obligation on developers to offer perpetual, unpaid maintenance. When this distinction is overlooked, maintainers can end up burdened with work that was never meant to be an open-ended personal commitment. Such an imbalance not only discourages openness, but also undermines the sustainability of an ecosystem that has become a vital part of modern society.

To explain the phenomenon occurring across the entire ecosystem: Developers write code they find useful and release it as FOSS. It gains popularity, and soon large corporations incorporate it into their products, reaping substantial profits. Requests for new features and fixes flood in, yet no financial support accompanies them. Eventually, the maintainer realizes there is no personal or professional benefit in responding to these unpaid demands. The skills required to develop popular FOSS are often in high demand in other fields as well. Ultimately, the maintainer burns out and the project is abandoned. This is the unsustainable cycle we are tackling.

Within this unsustainable cycle, adopting FOSS into products while fully aware of this situation is hardly beneficial for either companies or the society at large. To make the cycle sustainable, everyone must recognize the reality that someone must bear the costs, and these costs are equivalent to what companies would need to develop and maintain comparable products. This project specifically requests companies profiting from our deliverables to contribute to maintaining the project.

To be clear, this is not a request for charity; it is a proposal to manage the operational risk. This is a systemic challenge originating not from the developers, but from within the organizations that consume and whose business continuity depends on FOSS. Should a project be abandoned due to this unresolved problem, the primary victims will be you, the company that built its product on top of an unmaintained foundation, not the developers who can move on to other opportunities.

We request ongoing financial support from organizations that incorporate our project's deliverables into their products or services and derive annual revenue exceeding US $1 million from those products and services, to help cover the costs of maintenance and the development of new features. While this support is not a legal obligation, let us be clear: the license is a grant of permission to use our work, not a service contract obligating us to provide perpetual, unpaid labor. We consider it a fundamental business principle that to profit from a critical dependency while contributing nothing to its stability is an extractive and unsustainable practice.

It is also crucial to recognize what "maintenance" truly entails. In a living software project, it is not merely about preserving the status quo of the current version. It is the continuous effort that leads to security patches, compatibility with new environments, and the very features that define future versions. Therefore, to claim satisfaction with an older version as a reason to decline support, while simultaneously benefiting from the ongoing development that produces newer, better versions, is a logically inconsistent position.

This support must not be intended to benefit any particular company, but must support maintaining the project as a shared infrastructure that benefits all users and the broader community. Furthermore, this threshold is designed so that individual developers, small-scale projects, and the majority of our users are not asked to pay, while seeking appropriate support from companies that derive significant value from our project.

We understand that corporate procurement processes were not designed with FOSS sustainability in mind. We are committed to finding a practical path forward, but your partnership is essential in structuring a financial relationship that aligns with your standard corporate procedures. Our mutual goal is to treat this partnership as a conventional operational expense, removing your internal barriers and making sustainability a straightforward business practice.

Our goal is to maintain this project stably over the long term and make it even more valuable for all users. In an industry where many projects are forced to abandon FOSS licenses, our preference is to continue offering this project under a true open-source license. However, the long-term viability of this FOSS-first approach depends directly on the willingness of our commercial beneficiaries to invest in the ecosystem they rely on. We hope our collaborative approach can contribute to shaping a more balanced and enduring future for FOSS.

For details, please see our Code of Conduct or its introduction video. For reuse of this sustainability statement, see SUSTAINABILITY.md.

Copyright Naoki Shibata and contributors.