# IrScrutinizer: a workbench for capturing, decoding and generating infrared signals

> IrScrutinizer is a Java program for capturing, generating, analysing, importing and exporting infrared signals, developed by Bengt Martensson, whose repository was previously named harctoolboxbundle. It is a build-time utility as much as a desktop tool, with a Maven build, a Makefile that drives the tests and generates the lirc.xml export, and a reference manual, a tutorial and generated API documentation.

**bengtmartensson/IrScrutinizer** — IrScrutinizer is a program for IR signal analysis, decoding, generation and much more.

- Repository: https://github.com/bengtmartensson/IrScrutinizer
- Website: https://www.harctoolbox.org
- Stars: 529 · Forks: 60
- Language: Java
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/bengtmartensson-irscrutinizer

## A tool for the whole infrared signal lifecycle

IrScrutinizer is described as a program for IR signal analysis, decoding, generation and much more, and the README states the scope more plainly: it is a program for capturing, generating, analyzing, importing, and exporting of infrared signals.

That list is the product description, and it is worth reading in order because it marks a difference from the tools people usually reach for. A decoder takes a captured waveform and tells you which protocol it is and what the button presses were. A generator does the reverse, producing a waveform from a button press so you can test a remote or a receiver. Importing and exporting is the part that decides whether a tool is useful in practice, because it is how a signal you analysed gets turned into a configuration another program consumes.

The project sits in a family of infrared work. The repository topics list infrared, ir, ir-signals, ir-protocols, irp and irp-protocols, and lirc, and the last two tell you the two protocol vocabularies in play. IRP is a notation for describing infrared protocols, and LIRC is the long-standing Linux daemon whose configuration file format is effectively the interchange currency of the hobby. The Makefile in the repository confirms the LIRC connection concretely, since it notes that the Makefile invokes the program for tests and for transforming the output, for example to the lirc.xml file.

The author is Bengt Martensson, and the home page is harctoolbox.org, a site that has collected infrared tools for a long time. The GitHub repository was previously named harctoolboxbundle and has been renamed to IrScrutinizer, which documents the project's naming history.

The audience is therefore two overlapping groups, people who reverse engineer remotes and want a proper analysis environment, and people who maintain infrared configurations for a Linux media centre and need to generate and convert signal data.

## Three kinds of documentation, and where each one applies

The README points at three documentation sources, and they are aimed at different readers.

The reference manual is included in the distributions and can be read online at harctoolbox.org/IrScrutinizer.html. The README calls it the reference manual, which is the formal description of what the program does, and the same document is where the installation instructions live, in the appendix.

A tutorial is available separately on the hifi-remote.com wiki, under the page IrScrutinizer Guide. That wiki is the long-standing home of the home video enthusiast community that this project comes from, and the tutorial is the getting-started route rather than the specification.

The API documentation is generated and published at bengtmartensson.github.io/IrScrutinizer, with an important caveat attached: current version only. So the published API docs describe the version that was current when they were generated, not every release, which is the usual hazard with generated documentation and the reason to check the version before you rely on a signature.

Those three sources cover the three questions an adopter has. What does the program do, how do I start using it, and how do I call into it from code.

The distribution layout is worth noting as well. The reference manual is included in the distributions rather than only online, which is an old-fashioned choice that pays off on a machine with no reliable network connection, and it is also the document that the project treats as canonical, since the installation section of the README simply defers to the appendix of the manual and to a BUILD.md file in the repository that covers the same ground.

## Building: Maven does the work, the Makefile drives the project

The repository contains both a pom.xml and a Makefile, and the Makefile opens by explaining the division of labour, which is unusual and worth quoting in substance. The note says this Makefile is not required to build the program, for which maven is used, and instead it invokes the program for tests and for transforming the output, for example to the lirc.xml file.

So the build is Maven and the Makefile is the driver. The main artefact is a jar with dependencies:

```make
IRSCRUTINIZER_JAR := target/$(MYPROG)-$(VERSION)-jar-with-dependencies.jar

$(IRSCRUTINIZER_JAR):
	mvn package -Dmaven.test.skip=true
```

The naming tells you the packaging choice. A single jar with dependencies bundled is what lets you drop IrScrutinizer onto a machine with a JRE and run it, which is a reasonable thing to want for a tool that talks to infrared hardware on other people's machines.

The version is not written in the Makefile. It is read out of a generated file:

```make
VERSION=$(shell cat $(TOP)/target/$(MYPROG).version | cut  --delimiter=' ' -f 3)
```

So the version comes from the build output, and the Makefile derives the artefact name from it. The install location is fixed at /usr/local/share/irscrutinizer, and the Makefile pulls in a shared paths file from the common directory, which is how the same build works for the sibling tools in the project.

The installation of the dependencies themselves, which for this project means the native pieces, is not in the README at all. It is covered in detail in the appendix of the manual and in BUILD.md, and the presence of a native directory and a contributed directory in the tree explains why. The Java build is the easy half; the native half is where the instructions are needed.

## What the Makefile actually does for the maintainer

Beyond the jar, the Makefile is a set of release engineering steps, and reading them tells you how the project ships.

There is an apidoc target that generates the Javadoc site and opens it in a browser, and a target that regenerates the same site with mvn javadoc:javadoc. There is a version target that simply echoes the version. There is a setversion target that sets the version in the Maven project and commits it with a signature:

```make
setversion:
	mvn versions:set -DnewVersion=$(NEWVERSION)
	git commit -S -m "Set version to $(NEWVERSION)" pom.xml src/main/doc/$(PROJECT_NAME).releasenotes.txt
```

Two things stand out. The commit is signed with -S, and it touches the release notes file alongside the pom, so the version bump and the changelog entry are one atomic commit. Signing the release commit means that a published version can be traced to a key, which matters for a tool that people install and run against their own hardware.

The tag target then cuts a release from master:

```make
tag:
	git checkout master
	git status
	git tag -a Version-$(VERSION) -m "Tagging Version-$(VERSION)"
	git push orig
```

Which explains the release naming visible in the repository history. The tags are named Version-2.4.2 and Version-2.4.1, and the tag is created with a message of Tagging Version-$(VERSION). The push target is deliberately to a remote called orig rather than origin, which is a convention for a fork workflow, where origin is the contributor's fork and orig is the upstream project.

There is also a gh-pages target that regenerates the API documentation, clones the gh-pages branch of the origin remote, copies the generated site into it, commits and pushes. That is the mechanism behind the published API documentation, and it explains the current version only caveat, since the site is a snapshot taken at the last push of that branch rather than a per-release archive.

## Licence, support channels and the state of the tree

The licence is GPL version 3 or later, with the file named LICENSE.txt at the root of the repository, and the copyright line reads Bengt Martenson 2010-2022. The README adds a note that some contained third party components have different, but compatible, licences, and that this is documented elsewhere in the project.

That is the usual shape for a GPL project that has grown by absorbing other people's code, and it is worth checking the component licences yourself if you intend to redistribute a build, because the compatibility claim is the author's and the details live in a separate document rather than in the README.

Support is offered in three places, and the arrangement is characteristic of a project with a long life in a hobby community. There is GitHub Discussions for questions, and GitHub issues for bug reports and suggestions, with issues marked Help wanted as the place to find something to pick up. Beyond GitHub, the author participates in the JP1 forum on hifi-remote.com and on Remote Central, and says he will answer questions there.

That last point is the one to weigh. IrScrutinizer is, in part, a community tool for a niche hobby, and the people who know the protocol details are on those forums. A project whose maintainer answers questions on two specialist forums is a project whose real support channel is not its issue tracker.

The maintenance picture needs stating by date. The recent tags are a ci-build tag for a continuous build from 2025-11-30, Version-2.4.2 from 2025-02-17 and Version-2.4.1 from 2024-03-16, and the last push to the repository was on 2026-09-27. So the named release line has not moved since early 2025 while commits have continued, and the continuous build tag is the artifact that reflects the current state of the tree.

There is also a ROADMAP.md for future development and a CONTRIBUTING.md with the coding guidelines, and the README asks for all sorts of contributions rather than only code.

The primary language is Java, the build is Maven, and the Makefile is a convenience layer over it, and the tree is organised into src, common, contributed, native and tools, which is the layout of a project that has absorbed a family of related tools into one program.

## Conclusion

Adopt IrScrutinizer if you work with infrared remotes, whether to decode a protocol, generate a test signal, or produce a configuration file for an infrared daemon, since it covers the whole cycle rather than only the decoding step. Do not adopt it as a consumer of remote control codes, because it does not distribute or license any protocol data of its own. Verify first which Java and Maven versions the build expects, since the installation of the dependencies is covered in the appendix of the manual and in BUILD.md rather than in the README, check that you can use the API documentation matching the version you build, because the published API docs cover the current version only, and that you understand the distinction between the released tags and the continuous build tag, since the most recent named release is 2.4.2 from 2025-02-17 while commits have continued to the tree.

## FAQ

### What is IrScrutinizer?

It is a Java program for capturing, generating, analyzing, importing and exporting infrared signals, by Bengt Martensson. The GitHub repository was previously named harctoolboxbundle and has been renamed to IrScrutinizer, which reflects the merge of several separate infrared tools into one program.

### How do I build IrScrutinizer from source?

The build is Maven based: mvn package -Dmaven.test.skip=true produces target/IrScrutinizer-VERSION-jar-with-dependencies.jar. The Makefile is not required to build the program and exists to invoke the program for tests and for transforming the output, for example to the lirc.xml file. Installation of the dependencies, including the native ones, is covered in the appendix of the manual and in BUILD.md.

### Where is the IrScrutinizer documentation?

The reference manual is included in the distributions and readable online at harctoolbox.org/IrScrutinizer.html, a tutorial is on the hifi-remote.com wiki, and the generated API documentation is published at bengtmartensson.github.io/IrScrutinizer, which covers the current version only.

### What licence is IrScrutinizer released under?

GPL version 3 or later, with the copyright line reading Bengt Martenson 2010-2022 and the terms in LICENSE.txt. The README also notes that some contained third party components have different but compatible licences, documented elsewhere in the project.

### How are IrScrutinizer releases tagged?

The Makefile has a setversion target that uses mvn versions:set and commits the pom.xml and the release notes with a signed commit, and a tag target that checks out master and creates an annotated tag named Version-$(VERSION), which is why the release history shows tags like Version-2.4.2 alongside a separate ci-build tag for the continuous build.

## Sources

- [bengtmartensson/IrScrutinizer on GitHub](https://github.com/bengtmartensson/IrScrutinizer)
- [License: GPL-3.0](https://github.com/bengtmartensson/IrScrutinizer/blob/master/LICENSE)
- [Project website](https://www.harctoolbox.org)
- [README](https://github.com/bengtmartensson/IrScrutinizer/blob/master/README.md)
- [Releases](https://github.com/bengtmartensson/IrScrutinizer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bengtmartensson-irscrutinizer