At first, the choice can feel more complicated than it really is. WAV is often seen as the “studio quality” option, FLAC is popular with audiophiles and media server users, and ALAC is commonly associated with Apple devices.

The good news is that all three can store lossless audio. However, they are not equally convenient for long-term media storage.

In this blog, I will compare WAV, FLAC and ALAC from a practical storage perspective, including file size, metadata, compatibility, editing, and which format makes the most sense for different types of music libraries.

WAV vs FLAC vs ALAC: Quick Answer

For most people, FLAC is the best format for long-term media storage.

It gives you the same audio quality as WAV, usually uses much less space, supports metadata well, and works nicely with media servers like Plex, Jellyfin, Kodi, and many dedicated music players.

WAV still has its place, especially for recording, editing, sample libraries, and professional audio workflows, but it is usually not the most efficient format for storing a large music collection.

ALAC is also a great choice if you mainly live in the Apple ecosystem.

What Is WAV?

WAV, short for Waveform Audio File Format, is an audio container format originally associated with IBM and Microsoft. It is commonly used to store uncompressed PCM audio, although WAV can technically contain compressed audio too.

In simple terms, a typical WAV file stores raw audio data without trying to make the file smaller.

That makes WAV simple, widely supported, and excellent for editing. However, it also means the files can get very large.

For example, CD-quality audio at 16-bit / 44.1 kHz uses roughly 10 MB per minute in uncompressed stereo WAV format. A full album can easily take hundreds of megabytes.

WAV Pros

WAV is excellent when you want maximum compatibility with audio editors, DAWs, samplers, and professional tools. It is also simple to process because the audio is usually stored in an uncompressed format.

This makes WAV a great format for:

• Recording projects
• Audio editing
• Sample packs
• Temporary production files
• Exporting masters before final encoding

WAV Cons

The biggest problem with WAV is storage efficiency. Since typical WAV files are uncompressed, they take up much more space than FLAC or ALAC.

WAV can also be less pleasant for music library organization. Metadata support exists, but in practice, tagging WAV files is not always as consistent across music players compared to FLAC or ALAC.

If you are storing thousands of songs, this matters. Album art, artist names, track numbers, genres, and release dates are all important when browsing a media library.

What Is FLAC?

FLAC stands for Free Lossless Audio Codec. It compresses audio without losing quality, similar to how ZIP can compress files without changing their contents. Xiph.Org describes FLAC as lossless audio compression designed specifically for audio.

That means a FLAC file can be decoded back into the same audio data you would get from the original WAV source.

In other words, FLAC is not like MP3. MP3 throws away audio data to save space, and FLAC keeps the audio intact while still reducing file size.

FLAC Pros

FLAC is probably the best all-around format for storing a personal lossless music library.

It usually saves a lot of space compared to WAV, supports strong metadata tagging, is open, and is widely supported across many platforms and media players.

FLAC is especially useful for:

• CD rips
• Lossless music libraries
• Plex, Jellyfin, Kodi, and other media servers
• Archiving music without wasting space
• Keeping album art and metadata organized

FLAC files are also easy to verify. Since FLAC supports checksums, it is a very good format for people who care about long-term archival integrity.

FLAC Cons

The main downside is Apple compatibility. FLAC support is much better than it used to be, but ALAC still feels more native if you use Apple Music, iPhones, iPads, and macOS as your main music ecosystem.

FLAC is also compressed, so it takes a small amount of CPU power to decode. However, on any modern computer, phone, or media server, this is usually not a concern at all.

What Is ALAC?

ALAC stands for Apple Lossless Audio Codec. It is Apple’s lossless compression format. Apple says ALAC preserves the original audio data while reducing file size, and Apple Music uses ALAC for its lossless catalog.

ALAC is similar to FLAC in the most important way: it is lossless.

That means ALAC and FLAC can both store the same quality of audio. The main difference is ecosystem support.

ALAC Pros

ALAC is a great option if your music life revolves around Apple devices.

It works well with:

• Apple Music
• iPhone
• iPad
• macOS
• Apple TV
• AirPlay-focused setups

ALAC files are usually stored in .m4a containers, which also have good metadata support. If you want lossless files that feel native in Apple’s ecosystem, ALAC is often the easiest choice.

ALAC Cons

Outside of Apple-focused setups, ALAC is not usually as popular as FLAC.

Many apps and media servers can play ALAC just fine, but FLAC tends to be the more common standard among audiophiles, archivists, home server users, and open-source media tools.

If you are building a media library that you want to keep flexible across many systems, FLAC is usually the safer long-term bet.

WAV vs FLAC vs ALAC File Size

File size is one of the biggest reasons to choose FLAC or ALAC over WAV.

A WAV file usually stores audio without compression. FLAC and ALAC compress the same audio data losslessly, so they can reduce storage use while keeping the same quality.

A rough comparison for CD-quality music:

The exact savings depend on the music. Simple acoustic music may compress better than dense electronic or metal tracks. Still, FLAC and ALAC are usually far more storage-friendly than WAV.

For a small collection, WAV may not seem like a big deal. For thousands of albums, the difference can become massive.

Does FLAC or ALAC Sound Worse Than WAV?

No. FLAC and ALAC do not sound worse than WAV when they are created properly from the same source.

They are lossless formats. When decoded, they reproduce the original audio data.

The difference is not sound quality. The difference is storage, tagging, compatibility, and workflow.

If you convert a WAV file to FLAC and then decode that FLAC back to WAV, the audio data should match. The FLAC file is simply a more efficient way of storing it.

However, this only applies if the source is truly lossless. Converting an MP3 to FLAC does not restore lost quality. It just creates a larger file containing already-damaged audio.

I covered that problem in more detail in my guide on identifying fake FLAC files: How to Identify Fake FLAC Files

Metadata and Library Organization

Metadata is where FLAC and ALAC really shine for media storage.

When you are managing a large music library, you usually want:

• Artist
• Album
• Track title
• Track number
• Genre
• Year
• Album art
• Disc number
• Composer
• ReplayGain or loudness tags

FLAC handles this very well. ALAC also handles metadata well, especially in Apple software.

WAV can store metadata, but support is not as consistent across players and tagging tools. This makes WAV less ideal for a neatly organized personal music library.

For media storage, metadata matters almost as much as audio quality. A perfectly preserved WAV collection is annoying if half your album art, track numbers, or artist tags do not show correctly.

Compatibility: Which Format Plays Everywhere?

WAV has the broadest basic compatibility. Almost anything can open a WAV file.

FLAC is extremely well supported across modern media players, servers, and audio tools. It is especially common in open-source and home media server setups.

ALAC is strongest inside the Apple ecosystem. It is also supported by many modern players, but it is not usually the default choice for non-Apple media libraries.

Here is the practical breakdown:

When Should You Use WAV?

Use WAV when you are actively working with audio.

For example, WAV makes sense when recording vocals, editing podcasts, exporting stems, creating samples, or moving files between DAWs.

It is simple, uncompressed, and widely accepted by professional tools.

However, once the project is done, you may want to store the final version as FLAC or ALAC to save space while keeping the audio lossless.

Think of WAV as a production format, not always the best library format.

When Should You Use FLAC?

Use FLAC when you want the best general-purpose format for storing lossless music.

This is what I would choose for a personal archive, a home server, or a large music collection that needs to remain flexible over time. FLAC is what I use for my media server.

FLAC is especially good if you care about open formats, metadata, file integrity, and compatibility with media server software.

For most TechOpt readers who are building a home media setup, FLAC is probably the best default choice.

When Should You Use ALAC?

Use ALAC if you are heavily invested in Apple devices and want lossless audio that fits nicely into that ecosystem.

If your main playback devices are an iPhone, iPad, Mac, Apple TV, or Apple Music app, ALAC can be more convenient than FLAC.

It is also a good choice if you want to sync local lossless files through Apple-friendly workflows.

However, if you are trying to build a more platform-neutral archive, I would still lean toward FLAC.

Should You Convert WAV to FLAC?

Yes, in many cases.

If you have a large WAV music collection that you are using for listening and storage rather than active editing, converting it to FLAC can save a lot of disk space without reducing quality.

Just make sure you keep a backup before doing any large batch conversion.

A common workflow is:

1. Keep active recording projects in WAV.
2. Export finished masters as WAV.
3. Convert final listening copies to FLAC.
4. Store the FLAC files in your main media library.
5. Keep original project files separately if needed.

This gives you the best of both worlds: production flexibility and efficient storage.

Should You Convert FLAC to ALAC?

Only if you need better Apple compatibility.

Converting FLAC to ALAC should preserve audio quality because both formats are lossless. However, you should still be careful with metadata during conversion.

Some tags may not transfer exactly depending on the software you use.

If your FLAC library already works with your devices, there is no urgent reason to convert it. But if you want everything to feel native in Apple Music or on iOS, ALAC may be worth it.

Should You Convert MP3 to FLAC or ALAC?

No, not for quality reasons.

Converting MP3 to FLAC or ALAC will not restore the audio data that was removed during MP3 compression. It will only create a larger lossless file that contains lossy audio.

This is one of the reasons fake FLAC files exist. Someone can take a lossy MP3, convert it to FLAC, and make it look like a high-quality file. But the missing audio information is still gone.

If you care about lossless quality, start from a true lossless source such as a CD rip, studio master, or legitimate lossless download.

Best Format for Media Servers

For media servers, I would usually choose FLAC.

It is efficient, open, reliable, and well supported by most serious media software. It also keeps your library easy to move between systems in the future.

If you are using Plex, Jellyfin, Kodi, Navidrome, or another self-hosted music setup, FLAC is a very practical choice.

WAV will work, but it wastes space.

ALAC may also work, but unless you specifically need Apple compatibility, FLAC is usually the more natural fit for a server-based library.

Final Recommendation

For most people, the best format for media storage is FLAC.

It gives you lossless quality, smaller files than WAV, strong metadata support, and excellent compatibility across modern media players and servers.

Choose WAV when you are recording, editing, exporting stems, or working in a professional audio environment.

Choose ALAC when you want a lossless library that works smoothly with Apple devices and Apple Music.

The simple rule is:

Use WAV for production, FLAC for archiving, and ALAC for Apple-focused playback.

That keeps your audio quality intact while making your library easier to store, manage, and enjoy.

The post WAV vs FLAC vs ALAC: Best Format for Media Storage appeared first on TechOpt.

The projects in this article are ones that the original Model B actually has adequate power to run without sacrificing usability or performance, not just “will run, but not well” projects.

Similarly, a lot of these should work with the Model A. However, keep in mind that the Model A only has 256 MB of RAM, which limits it further.

1. Raspberry Pi Print Server

Make an old USB printer WiFi and AirPrint compatible using an old Raspberry Pi with Raspbian. By connecting the printer to a USB port on the Pi and installing CUPS, you can share your USB printer with your network to make it wireless.

Additionally, CUPS also now supports broadcasting as AirPrint devices. Once the printer is setup in CUPS, you should be able to print to it from your Apple devices as well.

2. Pi-Based Digital Picture Frame

A digital picture frame is probably one of the lowest resource projects you can do. Therefore, this makes it perfect for the original Raspberry Pi. You’ll simply need an old screen with an HDMI input. You can even use a screen with a composite input, since the original Pi has a composite output!

Choose an OS, put your photos on your SD card or a USB key and install some image slideshow software. Some people even get creative with decorative framing around the screen.

3. Raspberry Pi Web Server

You can run a lightweight web server such as nginx or lighttpd on your older Raspberry Pi to serve static web pages and basic websites. You can also try Apache, but keep in mind that Apache is not as lightweight as nginx or lighttpd, so your performance probably won’t be as good.

The original Pi Model B definitely isn’t powerful enough to serve a website to hundreds of users, however, for a few users it should be more than adequate.

4. Self-Host Bitwarden

This is one of my personal favourites. Bitwarden is an opensource password manager that you can self-host. It has accompanying desktop apps, mobile apps, and browser extensions.

The original Pi may not be powerful enough to host full Bitwarden, but it will easily run Vaultwarden. Vaultwarden is an alternative implementation of the Bitwarden API written in Rust, which makes it super fast and less resource-intensive than full Bitwarden. You can still use it with the official Bitwarden apps and extensions.

Simply install docker and spin up the Vaultwarden container. Again, it might not work great for hundreds of users, but our Pi 1 Vaultwarden instance is working great for our family of 6!

5. Internet Radio, Bluetooth or AirPlay Receiver

This one is also a personal favourite to modernize an old stereo system. All you need is a stereo system or set of speakers with an AUX port. This way you can connect the headphone jack of the Raspberry Pi right into the stereo system. Alternatively, if the stereo is older and has an RCA input, you can use a 3.5 mm to RCA adapter.

Install an OS and run your favourite music apps to play directly to your speakers. Additionally, you can setup Bluetooth pairing to use it as a Bluetooth speaker. You can also install shairport-sync to support AirPlay from Apple devices.

Conclusion

The Pi has come a long way since it was first introduced. Even though at first glance the original Raspberry Pi 1 Model B looks severely under-powered by today’s standards, it still has some great uses for applications where a lot of processing power isn’t needed.

The post Raspberry Pi Model B Original (2012) Uses in 2026 appeared first on TechOpt.

Why the Old --releasever Method No Longer Works

In my previous guide, I showed how you could upgrade openSUSE Leap releases with:

sudo zypper --releasever=16.0 dup

That used to work reliably in earlier Leap versions. However, with SLE (SUSE Linux Enterprise) 16, SUSE introduced major backend and repository format changes. The new openSUSE Leap 16.0 release merges more closely with SLE infrastructure, which means the repositories and release metadata formats have changed significantly.

If you try to use the --releasever flag now, you’ll likely see repository or GPG key errors during the upgrade. That’s because the old repository layout no longer matches Leap 16’s new structure.

The New Official Method: opensuse-migration-tool

Instead of manually changing repositories, Leap 16 introduces a dedicated migration utility designed to handle all the details for you. The tool automatically adjusts your repositories, resolves new dependencies, and manages system configuration changes.

Step 1: Install the Migration Tool

First, fully update your Leap 15.6 system:

sudo zypper refresh
sudo zypper up

Then install the new migration package:

sudo zypper install opensuse-migration-tool

Step 2: Run the Migration Process

Start the migration utility:

sudo opensuse-migration-tool

The tool will analyze your current system, identify obsolete packages, and suggest repository transitions for Leap 16.0. The system prompts you to confirm before proceeding with the distribution upgrade.

You’ll want to select openSUSE Leap 16.0 with the arrow keys on your keyboard, select OK and hit Enter.

You will probably encounter the following screen about disabling third-party repositories:

This happens because Leap 16.0 changes how repositories are structured. You can simply hit Enter to confirm.

The upgrade process will then start! Wait a few minutes, then reboot into Leap 16.0 once the process finishes.

Step 3: Reboot into Leap 16.0

After the migration completes, simply reboot:

sudo reboot

You’ll now be running openSUSE Leap 16.0 with the updated repository structure.

Troubleshooting Tips

• Do not use zypper dup --releasever=16.0. It may break dependencies.
• If you encounter repository signature errors, remove or rename old .repo files in /etc/zypp/repos.d/ before re-running the migration tool.
• Ensure your disk has sufficient space and that all third-party repositories are disabled before starting the upgrade.

Final Thoughts

The openSUSE team has streamlined the upgrade path to make system migrations more reliable and aligned with SUSE’s enterprise ecosystem. While older zypper --releasever methods are now deprecated, the openSUSE Migration Tool simplifies the process and ensures compatibility with the new Leap 16 architecture.

The post Upgrade openSUSE Leap to 16.0 from 15.6 appeared first on TechOpt.

This comprehensive guide will walk you through everything you need to know, from selecting the right cable and connectors, to crimping, testing, and troubleshooting your custom cables.

Why Make Your Own Ethernet Cable?

There are several advantages to building your own network cables:

• Custom Lengths: No more coiled-up mess or cables that come up just short. Instead, you can make cables the exact length you need.
• Cost Savings: Bulk ethernet cable and connectors are far cheaper per foot than buying pre-made cables.
• Better Quality Control: You choose the cable type, shielding, and connectors, therefore avoiding cheap copper-clad aluminum (CCA) cables.
• Skill Building: This is a useful DIY skill for anyone interested in networking, home labs, or IT work.

Tools and Materials Needed

Here’s what you’ll need to make DIY ethernet cables successfully:

• Ethernet Cable (Cat6, Cat6a, or Cat5e): Prefer solid copper rather than CCA for best performance and compliance with standards. Cat6 bulk cable on Amazon
• RJ45 Connectors: Choose connectors rated for your cable type (Cat6, Cat6a, or Cat5e). Passthrough connectors are easier for beginners. Cat6 RJ45 passthrough connectors
• RJ45 Crimping Tool: Used to secure connectors to the cable. Most crimpers also include a wire cutter and stripper. RJ45 crimp tool
• Cable Tester (Recommended, but optional): Ensures your wiring is correct and detects any faults. Basic cable tester or advanced network tester
• Strain Relief Boots (Recommended, but optional): Add durability to the connector ends. Strain relief boots
• Wire Cutters/Scissors: For trimming cable and internal wires. Wire strippers/cutters

Tip: Avoid “Cat7” or “Cat8” cables sold cheaply online. These are not officially recognized Ethernet standards and often use questionable materials.

Step 1: Measure and Cut Your Cable

Pull the amount of cable you need from the box, then add roughly 30 cm (about 1 foot) of extra length for trimming and flexibility. Cut the cable cleanly using the crimper’s cutting blade or a pair of wire cutters.

Step 2: Strip the Outer Jacket

Use the stripping blade on your crimping tool (or a dedicated wire stripper) to remove 5–10 cm (2–3 inches) of the outer jacket from both ends of the cable. Be careful not to nick the internal wires.

After that, remove the internal string, if present.

At this stage, slide on the strain relief boots if you’re using them—forgetting them is a common mistake. Therefore, it’s best to add them now. You want the larger side facing outward from the end of the cable on both sides.

Step 3: Untwist and Arrange the Wires

Inside the jacket are four twisted pairs of wires (8 total). Untwist the pairs and straighten them.

Then, arrange them in either T-568A or T-568B wiring order. Use the same standard on both ends.

T-568A Wiring Order:

1. White/Green
2. Green
3. White/Orange
4. Blue
5. White/Blue
6. Orange
7. White/Brown
8. Brown

T-568B Wiring Order (Most Common in North America):

1. White/Orange
2. Orange
3. White/Green
4. Blue
5. White/Blue
6. Green
7. White/Brown
8. Brown

Lay the wires flat and keep them in the correct order. Finally, flatten them gently with your thumb for easier insertion.

Step 4: Trim Wires to Length

For non-passthrough connectors, trim the wires so that they are just long enough to reach the end of the connector when inserted. Cut them evenly so they line up perfectly.

For passthrough connectors, leave them a bit longer since the ends will protrude and be trimmed after crimping.

Step 5: Insert Wires Into the RJ45 Connector

Slide the wires into the connector carefully, ensuring they remain in the correct order. Push firmly until:

• Each wire reaches the very end of the connector.
• The outer jacket passes the strain relief tab for a strong connection.

For passthrough connectors, the wires should stick out slightly from the other side.

As soon as you confirm the order, you’re ready to crimp.

Step 6: Crimp the Connector

Place the connector into the crimping tool and squeeze firmly until the pins press down into the wires and the strain relief tab locks onto the outer jacket.

Additionally, for passthrough connectors, trim the wire ends flush with the connector after crimping.

Then, repeat this entire process for the other end of the cable!

Step 7: Test Your Cable

Use a cable tester to confirm that all eight wires are connected in the correct order.

The lights on both ends should flash in sequence.

If any wires are misaligned, cut off the connector and repeat the process on that side.

Once confirmed, your custom ethernet cable is ready for use!

Cat6 vs Cat6a vs Cat5e: Which Should You Choose?

Not all Ethernet cables are created equal. Therefore, here’s a quick comparison to help you decide:

Recommendation: Use Cat6 for most home setups, Cat6a if you want to future-proof or need maximum performance for longer runs, and Cat5e only if you already have it on hand or are working with very low-cost builds.

Frequently Asked Questions

Q: Can I mix T-568A on one end and T-568B on the other?
A: Only if you are intentionally creating a crossover cable. Otherwise, use the same wiring standard on both ends.

Q: How long can an Ethernet cable be?
A: Standard twisted-pair Ethernet cables (Cat5e, Cat6, Cat6a) are rated for up to 100 meters (328 feet) in total length. This includes patch cables at both ends. Beyond this length, you may experience signal loss or reduced speeds.

For 10 Gbps on Cat6, keep runs under 55 meters; use Cat6a for longer 10 Gbps runs.

Q: Do I really need a cable tester?
A: While optional, it saves time and frustration by catching miswires before you plug into your network.

Q: Should I ever use CCA cable?
A: No. Instead, always use solid copper cable for performance, safety, and compliance with Ethernet standards.

Troubleshooting Common Issues When Making Ethernet Cables

• Tester Shows Miswired Pair: Re-check wiring order on both ends, re-crimp if needed.
• Cable Doesn’t Click Securely: Ensure the strain relief tab is pressed down properly during crimping. Also ensure that the release tab covers on your strain relief boots aren’t too stiff and pressing down on the release tabs of the RJ45 connectors as a result. You may want to work the rubber of the strain relief boots with your thumbs a bit to stretch and break them in.
• Poor Network Speeds: Test on another device and verify that you’re using solid copper cable, not CCA.

Final Remarks

Learning how to make ethernet cables saves money, eliminates clutter, and gives you full control over your network setup. Whether you’re wiring a home office, building a home lab, or just need a few short patch cables, this DIY approach is a game changer.

Practice a few times and you’ll be making professional-quality network cables in minutes!

If you prefer a video guide, you can watch my video guide below.

The post How to Make Ethernet Cables: A Complete Step-by-Step Guide appeared first on TechOpt.

In this post, I’ll break down:

• Why next/dynamic causes flickering
• Why it’s worse with nested dynamic components
• When dynamic() is still safe to use
• A practical alternative using React.lazy() and Suspense
• What trade-offs to expect when switching

The Flickering Problem in Next.js

Using dynamic() from next/dynamic is a great way to lazy-load components and reduce your JavaScript bundle size. It also supports options like { ssr: false } to only load components on the client side.

However, when you use these components with the App Router, they often cause a flash of missing or unstyled content, especially during fast navigation or when conditionally rendering dynamic components.

Nested dynamic() calls tend to amplify this issue. For example, a parent component conditionally loading a child via dynamic(), which in turn loads another sub-component dynamically, can make the flickering more severe.

This issue has been reported in GitHub issues and community threads, but a rock-solid fix hasn’t yet made it into the framework.

Interestingly, this flicker seems to affect nested dynamic components more than top-level ones. In my testing, first-level dynamically rendered components used directly in the page file rarely exhibit the issue, which means it’s generally safe to use next/dynamic there to avoid flash of unstyled content (FOUC) during initial mount.

The Better Alternative: React.lazy() + Suspense

One workaround that has proven effective is switching from next/dynamic to native React.lazy() with Suspense. This approach introduces fewer hydration inconsistencies and minimizes flickering, even with nested lazy-loaded components.

Use next/dynamic for components initially rendered on the page, and use React.lazy() for nested components that are rendered conditionally inside those components.

Example 1: Top-level safe usage with next/dynamic

import dynamic from 'next/dynamic';
import { isSignedInAsync } from '../auth';

const PageShell = dynamic(() => import('../components/PageShell'));

export default async function Home() {
  const isSignedIn = await isSignedInAsync();

  if (isSignedIn) return null;

  return <PageShell />;
}

In this example, PageShell is conditionally rendered on the server using dynamic components. This is safe since the dynamic component is rendered with the initial HTML from the server.

Example 2: Nesting with React.lazy() and Suspense

"use client";
import dynamic from 'next/dynamic';

const NestedComponent = dynamic(() => import('./NestedComponent'));

export default function PageShell() {
  const [showNested, setShowNested] = useState(false);

  return (
    <div>
      <h1>Welcome</h1>
      <button onClick={() => setShowNested(true)}>Load Nested Component</button>
      {showNested && (
        <Suspense fallback={<div>Loading nested...</div>}>
          <NestedComponent />
        </Suspense>
      )}
    </div>
  );
}

We can safely use React.lazy() and Suspense inside our dynamically-rendered PageShell component to conditionally render our NestedComponent, and still benefit from lazy-loading and code-splitting.

If we try using the dynamic function instead of React.lazy here, we may get the Next.js dynamic flicker.

Trade-offs of Using React.lazy() Instead of dynamic

While React.lazy() and Suspense often result in smoother rendering, there are two notable downsides:

1. No Server-Side Rendering

Unlike next/dynamic, which lets you disable or enable SSR, React.lazy() only supports client-side rendering. This might hurt SEO if your component needs to be visible to crawlers.

2. Flash of Unstyled Content (FOUC) on Mount

If you do try to use React.lazy() for SSR and use it in the server-rendered HTML, React.lazy() may cause a brief flash of unstyled content because the Next.js bundler doesn’t automatically include the styles for components loaded through React.lazy() in the server-rendered HTML. This limitation can lead to inconsistent rendering.

This is why it’s best to use next/dynamic for components that are visible in the server-rendered HTML, ensuring that styles and structure are present at first paint, while reserving React.lazy() for non-critical or nested components. Using next/dynamic in the initial server-rendered HTML does not seem to cause flickering.

Final Thoughts on Preventing the Next.js Dynamic Flicker

If you’re seeing flickering with next/dynamic and conditional rendering, especially in complex nested layouts, you’re not alone. While the Next.js team continues to evolve App Router, switching to React.lazy() and Suspense where you can may provide a smoother user experience at this time.

To summarize:

• Use next/dynamic safely for top-level page components
• Use React.lazy() for nested dynamic imports to reduce flicker

The post Solving Next.js dynamic() Flicker with React.lazy appeared first on TechOpt.

> Task :react-native-device-country:prepareLintJarForPublish
> Task :react-native-device-info:createFullJarRelease
> Task :react-native-device-info:extractProguardFiles
> Task :react-native-device-info:generateReleaseLintModel
> Task :react-native-device-info:prepareLintJarForPublish
> Task :react-native-fbsdk-next:createFullJarRelease
> Task :react-native-fbsdk-next:extractProguardFiles
> Task :app:stripReleaseDebugSymbols
> Task :react-native-fbsdk-next:generateReleaseLintModel
> Task :app:buildReleasePreBundle FAILED
> Task :app:uploadCrashlyticsMappingFileRelease
[Incubating] Problems report is available at: file:///Users/dev/Documents/app/android/build/reports/problems/problems-report.html
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:buildReleasePreBundle'.
> Sequence contains more than one matching element.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to https://docs.gradle.org/8.14.1/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
BUILD FAILED in 1h 6m 21s
1222 actionable tasks: 1208 executed, 14 up-to-date
node:child_process:966
    throw err;
    ^
Error: Command failed: ./gradlew bundleRelease
    at genericNodeError (node:internal/errors:984:15)
    at wrappedFn (node:internal/errors:538:14)
    at checkExecSyncError (node:child_process:891:11)
    at Object.execSync (node:child_process:963:15)
    at /Users/dev/Documents/app/buildscripts/buildserv/build/build-android.js:8:23
    at Object.<anonymous> (/Users/dev/Documents/app/buildscripts/buildserv/build/build-android.js:11:3)
    at Module._compile (node:internal/modules/cjs/loader:1529:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1613:10)
    at Module.load (node:internal/modules/cjs/loader:1275:32)
    at Module._load (node:internal/modules/cjs/loader:1096:12) {
  status: 1,
  signal: null,
  output: [ null, null, null ],
  pid: 22055,
  stdout: null,
  stderr: null
}
Node.js v20.19.3
Cleaning up project directory and file based variables 00:00
ERROR: Job failed: exit status 1

If you noticed from the stack trace above, this is a React Native app. I tried deleting my node_modules folder, deleting my build folders, running ./gradlew clean. I would run the build again and again, but nothing worked. The same error kept popping up every time, right near the end of the build.

No amount of –debug or –stacktrace was giving me any sort of additional information. The most information I could get from this error had already been given to me.

ChatGPT and Copilot were no help, suggesting that this is a Kotlin error and most likely resides in a native library I’m using within the app.

But this didn’t make sense, because I was able to build the project on my local system with the latest dependencies just fine. It was only once I sent the build to my GitLab instance, which runs the build on a macOS VM with gitlab-runner, that I started getting this error.

So is the error with the build process, or one of the build tools itself?

Narrowing Down the Cause

After a ton of googling of this error, I finally came across this Google IssueTracker post that pointed me in the right direction. This person describes the exact same issue I’m having.

This person also says that this error started happening after an upgrade to AGP 8.9.0.

Now we’re getting somewhere. It doesn’t look like they’re using React Native, but at this point I was confident the issue isn’t stemming from anything to do with React Native.

AGP is an Android build tool. It’s possible that my macOS VM has a newer version of AGP than my local system does. This would explain why it’s only happening once I send the app to build in the macOS VM.

So, what’s the problem?

Well, it can be traced back to this section here in the app’s build.gradle:

...
splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false
            include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
        }
    }
...

This section of the build.gradle file tells gradle to output different APK files for different CPU architectures.

When this part of the build.gradle file is encountered by running the bundleRelease gradle task, the “sequence contains more than one matching element” exception is thrown because bundleRelease expects to be generating a single universal AAB file instead of separate APK files, that can then be uploaded to the Google Play Store.

The Fix

All I did was remove this section from our build.gradle file:

...
splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false
            include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
        }
    }
...

And it resolved the issue! We weren’t using the multiple APKs anyways, so I’m not even sure why we had this in our build.gradle file. We only upload the single universal AAB to the Play Store.

Additional Notes

In the issue tracker linked above, Google states that they do not plan on fixing this, since they don’t officially support creating multiple APKs when running bundleRelease. However, if you still need multiple APK support, someone on the issue tracker suggests the following fix:

splits {
        abi {
            // Detect app bundle and conditionally disable split abis
            // This is needed due to a "Sequence contains more than one matching element" error
            // present since AGP 8.9.0, for more info see:
            // https://issuetracker.google.com/issues/402800800

            // AppBundle tasks usually contain "bundle" in their name
            val isBuildingBundle = gradle.startParameter.taskNames.any { it.lowercase().contains("bundle") }

            // Disable split abis when building appBundle
            isEnable = !isBuildingBundle

            reset()
            //noinspection ChromeOsAbiSupport
            include("armeabi-v7a", "arm64-v8a", "x86_64")

            isUniversalApk = true
        }
}

This enables APK splitting while disabling APK splitting for the bundleRelease task, preventing the “sequence contains more than one matching element” error.

The post Fixing ‘Sequence contains more than one matching element’ Android Build appeared first on TechOpt.

While there’s no foolproof method to detect a fake FLAC, there are some telltale signs based on bitrate and frequency response that can help you spot them. One of my go-to tools for this task is Spek, a free and open-source audio spectrum analyzer.

What Is a Fake FLAC or Fake Lossless Files?

People create fake FLAC files by converting lossy formats—like MP3 or AAC—into lossless containers such as FLAC. Although the file extension and size might suggest high quality, the underlying audio data remains compromised. These files often originate from people who re-encode lossy sources and redistribute them under the guise of high fidelity.

Also note that while FLAC is the most common lossless audio format, other containers such as WAV and ALAC do exist as well. The indicators mentioned in this article for spotting fake lossless audio files are generic and apply regardless of the container format.

Using Spek to Analyze Frequency Spectrum

When you open a file in Spek, it displays the audio spectrum across the entire track. This visual representation reveals how much of the frequency range the file actually contains. A true lossless FLAC will have no abrupt cutoffs in the upper frequencies, whereas fake FLACs often exhibit sharp drop-offs.

Here’s a general guideline for identifying the cutoff frequencies and their corresponding bitrates:

• 11 kHz = 64 kbps
• 16 kHz = 128 kbps
• 19 kHz = 192 kbps
• 20 kHz = 320 kbps

If you notice a sharp cutoff around these frequencies, the file may have been upsampled from a lossy source.

What to Expect from True Lossless FLACs

Depending on the sample rate and bit depth, a legitimate FLAC file should show frequency content extending to the upper limits of the spectrum:

• 44.1 kHz, 16-bit: Should display frequencies up to 22 kHz
• 48 kHz, 16-bit: Should reach up to 24 kHz
• 96 kHz, 24-bit: May extend up to 48 kHz, but a smooth fade to nothing somewhere between 20-30 kHz is normal
• 192 kHz, 24-bit: May extend up to 96 kHz, but a smooth fade to nothing somewhere between 20-30 kHz is normal

You can often spot upsampling when you see a sharp cutoff at 22 kHz. There may also be very faint or random noise in the 22 kHz and up range. This pattern usually means someone took a 44.1 kHz file and padded it to 48 or 96 kHz.

It’s also worth noting that there’s ongoing debate about whether audio content above 20 kHz contributes meaningfully to music. An audio engineer or producer might even intentionally apply a low-pass filter to cut out all frequencies above a certain inaudible range. This will result in a steeper drop-off, even in a genuine lossless file.

Additionally, not all instruments produce frequencies in this high range, so a natural lack of content above 20 kHz doesn’t necessarily indicate the file is fake.

Bitrate as Another Indicator of a Fake FLAC

Another clue is the file’s bitrate. While FLAC is a variable bitrate format, files with noticeably low average bitrates may be suspect. Here are some average bitrate ranges you might expect from real FLAC files:

• 44.1 kHz / 16-bit (CD quality): ~700–1100 kbps
• 48 kHz / 16-bit or 24-bit: ~800–1400 kbps
• 96 kHz / 24-bit: ~2000–3000 kbps (can vary widely depending on the content)
• 192 kHz / 24-bit: ~4000–7000 kbps (can vary widely depending on the content)

If you see a file with a much lower bitrate than expected and frequency cutoffs that match the patterns listed above, the file is almost certainly a fake FLAC.

Trust Your Ears

While visual analysis is helpful, always trust your ears. A song that sounds dull, muffled, or artifacted is likely not true lossless. That said, some minimal or acoustic recordings might not use the entire frequency spectrum and can still be genuine FLACs.

For example, a solo vocal track, acoustic guitar piece, or lo-fi bedroom recording may naturally have limited frequency content, especially in the high end. These types of recordings often focus on midrange clarity rather than full-spectrum detail, so a sparse frequency graph in Spek doesn’t always mean the file is fake.

Final Thoughts

Detecting fake FLAC files takes a combination of tools, knowledge, and critical listening. While Spek and bitrate guidelines provide strong indicators, no method is 100% reliable. Still, by learning to recognize the red flags, you can better curate a truly lossless music library.

The post How to Identify Fake FLAC Files appeared first on TechOpt.

There are benefits to using a Microsoft account with your PC, but you might still want to use a local account. Some people prefer using a local account for administrative or privacy reasons. Also, you can always sign-in to a Microsoft account at a later time.

You can still create a local account during initial setup, but it’s harder than before. Here are the steps for skipping Microsoft account login and creating a local account in newer versions of the Windows 11 Home out-of-box setup experience.

1. Proceed Through Initial Setup Until the Microsoft Account Screen

Proceed through the initial setup steps by configuring the options and clicking Next. You’ll eventually wind up at the Microsoft account screen.

2. Open Command Prompt from Setup with SHIFT+F10

Once you’re in the initial setup wizard shown above, press SHIFT+F10 on your keyboard. This will open a command prompt window.

3. Type start ms-cxh:localonly and Hit Enter

Click inside of the command prompt window and type start ms-cxh:localonly.

Hit Enter.

4. Create a Local Account

A new screen will open to create a local account. Type a username, password and choose your security questions.

When you’re done, simply click Next to proceed to the desktop as you normally would!

Remarks

• Although you can technically run this command at the beginning of setup, it’s best to get to the Microsoft account screen first to easily configure your system’s region, keyboard settings and network.
• As of right now, you can still create a local account on Windows 11 Pro and Enterprise versions from the setup wizard.
• My opinion is that this clearly shows the direction Microsoft is taking with its consumer line of products. They want us to be reliant on their cloud as much as possible!

Update 05/08/2025: The command previously suggested in this article, oobe\bypassnro, has been disabled by Microsoft as of Windows 11 build 26100. Only the start ms-cxh:localonly command should be used going forward.

If you prefer a video to follow along, you can watch the tutorial on my YouTube channel down below:

The post Local Account Creation During Windows 11 Setup appeared first on TechOpt.

Why Is App Center Being Discontinued?

App Center has been a go-to choice for mobile developers, providing CI/CD capabilities, automated testing, and distribution for iOS and Android apps. However, Microsoft has decided to sunset the platform, leaving teams to find replacement services that meet their needs. Therefore, selecting the right alternative is crucial. The key factors in choosing an alternative include build automation, real-device testing, seamless app distribution, and over-the-air (OTA) updates.

Best App Center Alternatives for React Native

1. EAS (Expo Application Services)

For teams using EAS, it provides an all-in-one solution for building, updating, and distributing React Native apps. As a result, it is one of the best alternatives to App Center, especially for projects already leveraging Expo.

• Pros:
  • Seamless integration with Expo projects
  • No need for local machine setup
  • Cloud-based builds for iOS and Android
  • EAS Update serves as an alternative to CodePush, allowing for seamless OTA updates
• Cons:
  • Primarily geared toward Expo-managed projects
  • Limited flexibility for bare React Native apps

2. Hot Updater (Self-Hosted CodePush Alternative)

If you relied on App Center for CodePush, a crucial feature for deploying over-the-air updates, you need a replacement. Fortunately, one of the best open-source alternatives is Hot Updater. This is my personal favourite CodePush replacement. It provides similar functionality while allowing you to self-host your own OTA update solution.

• Pros:
  • Self-hosted, offering full control over updates
  • Supports both iOS and Android
  • Intuitive web console for managing versions
  • Plugin support for various storage providers (AWS S3, Supabase, etc.)
• Cons:
  • Requires infrastructure setup and maintenance
  • Needs DevOps expertise for proper implementation

3. Bitrise

Bitrise is one of the most popular CI/CD platforms for mobile development. It offers cloud-based automation, supports React Native out of the box, and provides a flexible pipeline system for building, testing, and deploying apps. Consequently, many teams transitioning from App Center have found it to be a reliable alternative.

• Pros:
  • Pre-configured workflows for React Native
  • Easy integration with GitHub, GitLab, and Bitbucket
  • Supports both iOS and Android
• Cons:
  • Limited free-tier resources
  • Learning curve for advanced workflow customization

4. Codemagic

Codemagic is another excellent CI/CD tool that specializes in mobile development. It supports React Native projects and simplifies the build and deployment process with minimal configuration. Additionally, its user-friendly approach makes it a strong choice for teams looking for a quick transition.

• Pros:
  • Optimized for React Native
  • Automated iOS code signing
  • Integration with Google Play and App Store
• Cons:
  • Can get expensive for teams with heavy usage
  • Limited concurrent builds on the free plan

5. Firebase App Distribution

If your primary need is distributing pre-release versions of your app, Firebase App Distribution is a great alternative to App Center’s distribution feature. Moreover, it integrates well with other Firebase tools, making it an appealing choice for teams already using Firebase.

• Pros:
  • Easy tester management
  • Integrates with Firebase Crashlytics for monitoring
  • Works for both iOS and Android
• Cons:
  • No built-in CI/CD
  • Requires additional tools for automated builds

Choosing the Right App Center Alternative for Your React Native Project

The best App Center alternative depends on your specific needs:

• For full CI/CD: Bitrise or Codemagic
• For scalable builds: CircleCI
• For Expo projects: EAS (Expo Application Services)
• For simple app distribution: Firebase App Distribution
• For over-the-air updates (CodePush alternative): Hot Updater

As App Center sunsets, transitioning to a new platform early will help ensure a smooth workflow. Consequently, by selecting the right alternative, you can continue to build, test, distribute, and update your React Native apps with minimal disruption.

The post App Center Alternatives for React Native Developers appeared first on TechOpt.

Warning

Use this method at your own risk. Modifying HTML responses through Nginx can easily break your webpage if not handled carefully. Always test changes in a controlled environment before deploying them to production.

Nginx is not designed for content manipulation, and this approach should only be used as a last resort. Before proceeding, exhaust all other options, such as modifying the source code, using a built-in integration, or leveraging a client-side solution.

How to Add a Script to HTML Using Nginx

If you need to add a script, or any other HTML to an HTML file using Nginx, you can use the sub_filter module to modify response content on the fly. By leveraging this, we can insert a <script> tag before the closing </head> tag in the HTML document.

Configuration Example

To achieve this, add the following to your Nginx configuration:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_buffering off;

        sub_filter '</head>' '<script src="https://example.com/analytics.js"></script></head>';
        sub_filter_types text/html;
        sub_filter_once on;
    }
}

Explanation

• sub_filter '</head>' '<script src="https://example.com/analytics.js"></script></head>': This replaces </head> with our script tag, ensuring it appears in the document head.
• sub_filter_types text/html;: Ensures the filter applies only to HTML responses.
• sub_filter_once on;: Ensures that the replacement happens only once, as </head> should appear only once in a valid HTML document.

Adding an Nginx Proxy for Script Injection

To implement this solution without modifying the existing helpdesk software, I set up another Nginx instance in front of it. This new Nginx proxy handles incoming requests, applies the sub_filter modification, and then forwards the requests to the helpdesk backend.

Here’s how the setup works:

1. The client sends a request to example.com.
2. Nginx intercepts the request, modifies the HTML response using sub_filter, and injects the script.
3. The modified response is then sent to the client, appearing as if it were served directly by the helpdesk software.

This approach keeps the original application untouched while allowing script injection through the proxy layer.

Remarks

• Nginx is primarily a proxy and web server, not a content manipulation tool. Modifying content in this way should be a last resort after exhausting all other options, such as modifying the source code, using a built-in integration, or leveraging a client-side solution. Overuse of sub_filter can introduce unexpected behavior, break page functionality, or impact performance.
• sub_filter requires proxy_buffering off;, which may degrade performance, especially for high-throughput sites, by preventing response buffering and increasing load on the backend.
• If you’re adding multiple scripts or need flexibility, consider using a tag manager such as Google Tag Manager instead.
• You can use this method to modify or inject any HTML, not just scripts.

The post Adding a Script Tag to HTML Using Nginx appeared first on TechOpt.