[Got the Shakes]

Maybe I was just misunderstanding how eARC worked, but I thought some of us raised a fuss over the initial A16 build because it wasn't modernized to pass HDR, which meant that it was going to hinder 4K players other than the sound, and similary with the consoles. Later that got updated, but I thought it was for HDR10 only, unless the way it works is somehow now different. For me, that became kind of a moot point though inevitably since my player has a dedicated audio only out as well, which is what I've been using with the A8.

I also have a 3080, but my current TV is limited to 60fps, so I think the only benefit I might have gotten out of 2.1 would have been Full RGB 4:4:4 at 60fps. I also only have ARC, but even though I have Atmos options with the TV, I'm assuming this means it likely won't work with the A16. Anyway, it's good to know that you can actually stream DV with the A16. I never even considered I'd be using it for that.

eARC only sends audio. So my HMDI 2.1 devices are connected directly to my TV and my TV displays the video. The TV then extracts the audio and sends it via eARC to the A16. For the devices connected to the A16's inputs the A16 processes the audio and passes through the video to my tv. It doesn't touch the video at all, it's just passthrough over HDMI to the tv. The is no eARC involved in that.

 

[Sanctuary]

No size limitation on the microSD cards, because it MUST be formatted FAT32. This supports long file names and large sizes of 16GB, 32GB, 64GB, etc..

The old 2GB SD cards for the A8 were formatted FAT, with file names that were 8.3.

Don't forget that in order to be imported into the A16 via microSD card they must first be exported from the A8 onto SD card being written out by the latest A8 firmware. This will create file names of HPEQ20xx.SVS and PRIR20xx.SVS and in the proper format usable by the A16 for importing. Then you copy them from the FAT/SD card out of the A8 onto a FAT32/microSD card for the A16, placing the files in the correct sub-folders as required for the IMPORT:

\Realiser\HPEQS
\Realiser\PRIRS

If you enable the BMP screenshot option (so that the # key in the lower-right corner of the remote takes a screenshot to the inserted microSD card), the resulting BMP files (each one 460.854 bytes in size) will all be placed in the parent \Realiser folder. This is a very useful feature for documentation, problem or question description, etc.

The screenshot itself takes about 5+ seconds to complete, during which the display screen "freezes" and a faint green light inside the microSD card reader drive lights up to indicate the drive is in use. The green light goes out and the screen will return to normal active presentation once the writing of the BMP file is finished. The BMP file names include date and time but otherwise no identifying info as to what the screenshot itself contains. You''ll simply have to look at the BMP files with an image browser on your computer and pick and choose as you like, renaming them according to your own purpose if you want to keep them permanently.

I'm assuming there hasn't been any A8 updates since 2018, which is when I got mine. I'll check the firmware, but I think it's from 2011. Also, I already tried formatting for FAT32, but it only allows NTFS and exFAT, I guess because it's larger than 32GB. I've read elsewhere that FAT32 and exFAT can be used interchangeably, so I hope that's the case here.

I also got another UPS update where they informed me of the import tax. Mine was $65, and they allowed me to pay it online, so that's out of the way at least.

edit: Is there a way to insert quotes after you've already posted a reply? Can't find an option anywhere to do that here.

 

[makan]

Note that the requirement for the AVR to be connected to the A16 in order for Atmos audio to be delivered to the A16 from apps is NOT TRUE for the four external sources connected to the HDMI inputs of the A16 itself.

In other words I can "disconnect" the AVR completely from the A16, and move the HDMI cable to the HDMI-out of the A16 (thus utilizing the A16 100% for sound, and passing on video from all sources directly to the TV... with no AVR involvement at all), and everything works perfectly! The Netflix app on all sources WILL deliver Atmos audio, of course only going as far as the A16 which then passes only video on to the TV. So the apps appear convinced that the A16 CAN accept Atmos.

However I'm not so convinced. I suspect it might be the connected TV itself... WHICH HANLDES ATMOS... that might be the "secret partner" here that is allowing the apps running on the source devices going into the A16 to deliver Atmos. Yes, just as with the TV's Netflix app that "sees the AVR" through the A16 via HDMI cable magic, and discovers that the AVR can handle Atmos, so the TV sends Atmos via eARC to the connected A16 which handles Atmos perfectly, in this second story maybe it is the TV itself which is the "silent partner" that says "I can accept Atmos". And hence the apps on the external devices send Atmos which gets picked off by the A16, so it all looks fine.

But perhaps even in this second seemingly successful story NOT INVOLVING THE AVR, perhaps it is again actually the downstream HDMI-connected device which is really testifying that Atmos is acceptable... and not the A16 all by itself! At least that's kind of how it appears. Without that secondary downstream device (either Atmos-capable TV of Atmos-capable AVR) connected via HDMI to the A16, the upstream app won't allow Atmos.

Now I can only prove this when I can actually see something on the TV screen, in order to navigate the source. Theoretically if I disconnect HDMI-out from the A16 (i.e. not going to either TV or AVR) then if my theory is correct none of the sources should be willing to deliver Atmos. Of course I need to be in the app, and navigate to the movie and press OK... all "blind" (since there's no TV connected) in order to prove that. I can see the audio coming into the A16 from its own display screen, but I need to get the app started playing a movie first. And flying "blind" is tricky.

But I will see if I can get that started successfully, and then see by the A16 whether it is getting 5.1 or Atmos.

well, I have ordered an HDMI cable and I will see if it will work with just the TV eARC to the A16. I have a Denon AVR from 2009 and so, I shouldn't be surprised that your trick to connect the AVR out to A16 in did not work. With auto on the TV, I get 5.1, but with passthrough, I get nothing, not even 5.1...so, hoping the new hdmi cable replacing my 2010 hdmi cable will pass the atmos to the A16

 

[dsperber]

I'm assuming there hasn't been any A8 updates since 2018, which is when I got mine. I'll check the firmware, but I think it's from 2011. Also, I already tried formatting for FAT32, but it only allows NTFS and exFAT, I guess because it's larger than 32GB. I've read elsewhere that FAT32 and exFAT can be used interchangeably, so I hope that's the case here.

I also got another UPS update where they informed me of the import tax. Mine was $65, and they allowed me to pay it online, so that's out of the way at least.

edit: Is there a way to insert quotes after you've already posted a reply? Can't find an option anywhere to do that here.

You cannot use NTFS or exFAT. The microSD card MUST be formatted as FAT32.

I don't know what you were trying to format your 64GB card with, but you will have no problem using this perfect utility to format anything of any size to FAT32. I've been using it for many years.

 

[dsperber]

well, I have ordered an HDMI cable and I will see if it will work with just the TV eARC to the A16. I have a Denon AVR from 2009 and so, I shouldn't be surprised that your trick to connect the AVR out to A16 in did not work. With auto on the TV, I get 5.1, but with passthrough, I get nothing, not even 5.1...so, hoping the new hdmi cable replacing my 2010 hdmi cable will pass the atmos to the A16

I honestly doubt that your 2009 AVR is going to cut it. The "premium certified" (and 18Gb/s) HDMI cable is really to support Dolby Vision and HDR. I'm pretty sure Dolby Atmos audio does not require that much bandwidth, so a lesser quality HDMI cable should be acceptable.

But I still feel it's the source/target device handshake that determines whether or not both Dolby Vision and Dolby Atmos can be used. Since my Yamaha RX-A1080 supports both Dolby Vision (passing video on to the connected TV) and Dolby Atmos (handling it in the AVR for presentation on the theoretically connected speakers, or down-mixing to 2ch-stereo or 7ch-stereo), as long as the downstream AVR is connected to the A16 then any source running to (i.e. eARC) or through (i.e. Roku, ATV4K or Shield) the A16 will deliver both Dolby Vision and Dolby Atmos.

Similarly, I believe that if I don't have the AVR connected to the HDMI-out of the A16 but instead have my LG C9 connected, so that it is only the A16 handling sound delivered from the external sources feeding the A16, the downstream TV (which itself can handle both Dolby Vision as well as Dolby Atmos through its internal speakers), once again the external sources running into the A16 will agree to deliver both Dolby Vision (passed on to the TV) and Dolby Atmos (peeled off by the A16 for delivery to headphones).

So, yet to be determined what your results will be even with a new HDMI cable. That cable is really probably only going to influence whether you get Dolby Vision video or not on the TV. As to whether you get Dolby Atmos, that is determined by whether you AVR can accept it and/or whether your TV can accept it. The A16 is simply paced in the middle of the end-to-end HDMI connections, and will peel off Dolby Atmos audio if the source device is willing to send it to the target device (which I feel is not the A16, but the downstream AVr or TV).

We shall see what you experience.

 

[Sanctuary]

You cannot use NTFS or exFAT. The microSD card MUST be formatted as FAT32.

I don't know what you were trying to format your 64GB card with, but you will have no problem using this perfect utility to format anything of any size to FAT32. I've been using it for many years.

Simply Windows 10, which is all I've ever needed to use. Would be really odd if exFAT didn't work though considering it was developed in 2006 and made with SD cards in mind. Thanks for the link. I'll just go ahead and format it now.

 

[dsperber]

Simply Windows 10, which is all I've ever needed to use. Would be really odd if exFAT didn't work though considering it was developed in 2006 and made with SD cards in mind. Thanks for the link. I'll just go ahead and format it now.

From page 130 of the latest A16 manual:

STEP 1. The new firmware for the Realiser A16 is uploaded through the micro-SD card slot on the front panel. First, obtain a micro-SD card
(commonly 8 or 16 GB) and ensure it is formatted as FAT32. Second, create a ‘realiser’ folder in the root directory and copy the firmware file
FIRMA001.SVS into the realiser folder. Insert this micro-SD card into the slot on the front of your A16.

The operating system inside the A16 apparently supports only the FAT32 file system through its card reader. What other file systems can be used on a microSD card is not relevant.

Anyway, that GUI format FAT32 utility will do the trick on any SD card or USB flash drive, of any size.

 

[shmau]

My understanding of Atmos is that it's not layout specific. Rather it creates sonic objects, and uses as many speakers (actual or virtual) to recreate those objects as you have in your layout. Thus whether you have 7.1.4, 9.1.6, or 15.1.8--all the speakers in the layout will be utilized and active.

Not entirely true, yes there can be objects but it doesn't mean everything will be an object. Bed layer still exists and matters. A bad Atmos mix could have very few objects in it.

https://learning.dolby.com/hc/en-us/articles/360052744252-Module-1-2-Beyond-Multichannel-Audio-

 

[Sanctuary]

From page 130 of the latest A16 manual:

STEP 1. The new firmware for the Realiser A16 is uploaded through the micro-SD card slot on the front panel. First, obtain a micro-SD card
(commonly 8 or 16 GB) and ensure it is formatted as FAT32. Second, create a ‘realiser’ folder in the root directory and copy the firmware file
FIRMA001.SVS into the realiser folder. Insert this micro-SD card into the slot on the front of your A16.

The operating system inside the A16 apparently supports only the FAT32 file system through its card reader. What other file systems can be used on a microSD card is not relevant.

Anyway, that GUI format FAT32 utility will do the trick on any SD card, of any size.

It kept giving me an error each time I tried to use it. "Failed to open device. The process cannot access the file because it is being used by another process". Happened each attempt, and restarting didn't help either. Ironically, I didn't need it since I already had a partition manager that I haven't needed to use in ages that I forgot about that worked no problem.

Also the latest firmware for the A8 shows 2019 on the file. Was this actually a new update from Revision 3 (2011)? Because that's what mine currently has.

For the A16, I'm assuming they shipped it with the most up to date firmware, but if for whatever reason they didn't, are there currently any new bugs that might have been introduced with it, and should I hold off on updating if so?

 

[dsperber]

How embarrassing. I just tried it myself to initialize a 128GB microSD flash card I had and got the same error you got. I also tried both the 32-bit and 64-bit versions, and they both failed the same way.

I've emailed the author, to see if he can explain its apparent "self-destruction". My x64 version is from back in 2018 and it's worked for me forever without a failure... until today.

I thought perhaps it was my BitDefender anti-virus somehow "protecting" the drive, since I can't imagine what other process might be using the device that would somehow be in conflict for what GUI Format FAT32 wants to do. But that seems unlikely.

Anyway I await a response for the software author, to see what he has to say.

Sorry for the completely unexpected problem. Honestly, I've used this utility for years without an issue!

 

[Sanctuary]

How embarrassing. I just tried it myself to initialize a 128GB microSD flash card I had and got the same error you got. I also tried both the 32-bit and 64-bit versions, and they both failed the same way.

I've emailed the author, to see if he can explain its apparent "self-destruction". My x64 version is from back in 2018 and it's worked for me forever without a failure... until today.

I thought perhaps it was my BitDefender anti-virus somehow "protecting" the drive, since I can't imagine what other process might be using the device that would somehow be in conflict for what GUI Format FAT32 wants to do. But that seems unlikely.

Anyway I await a response for the software author, to see what he has to say.

Sorry for the completely unexpected problem. Honestly, I've used this utility for years without an issue!

Not a problem at all. Well, for me at least. I would have inevitably searched out a converter of my own volition if I had needed to (card size notwithstanding), but you were just trying to help. Me getting that error is what reminded me of the program I already had installed that could do it anyway.

 

[dsperber]

Not a problem at all. Well, for me at least.

But it's really a problem for me. I can't imagine what's going on. And I certainly wouldn't have suggested it to you had I known any of this.

I did find this remark from some other web site (and there are many) that offers it for download:

"It does that by focusing on 512-kbyte sectors, and therefore it can be used only
on traditional spinning hard drives. To repeat once more, the FAT32 Format
desktop app is unsuitable and cannot be used on modern SSD hard drives."

Well, a microSD and standard SD flash card are obviously not spinning hard drives. But I know I've used it to initialize USB flash drives, which are also not spinning hard drives. So I still can't figure out what the story is here. And in fact I've NEVER used it to initialize a spinning hard drive, but only flash drives and cards. For example the 32GB, 64GB and 128GB microSD cards I've used in my Samsung phones (before they stopped making the phones with card readers for external storage, simply greatly increasing the size of the built-in solid state internal storage) were all initialized by this utility to FAT32 which is what the phone required.

Hopefully I will hear back from the author and learn about a reasonable explanation.

 

[sander99]

I was under the assumption that manLOUD was used with a listening room after all of the virtual speakers you wanted to use were populated, but that doesn't seem to be the case, and that it's strictly per PRIR?

You create a manLOUD using one specific PRIR, and in fact during that process only information from L+R, or C, or L+R+C (your choice) from that PRIR is used. All manuall changes that you apply to the HPEQ in this process are aimed at improving those front speakers.
Later you use this HPEQ in a preset, where it will apply to all speakers in the used listening room. (Because it is finally just one stereo EQ, applied to the stereo headphone signal after - or maybe I should say as the last step in - the speaker virtualisation process.)
Because it is applied to all speakers, but adjusted to suit the front speakers, the changes are pseudo-random to all the other speakers meaning other speakers could be improved, or get worse, or just different but not better or worse. The idea behind this is that the front speakers are more critical, and hopefully the other speakers won't be screwed up too much!

I think that if the other speakers are from other PRIRs or BRIRs then the chance of getting all speakers to sound fairly realistic will decrease, but still maybe it is worth to try (if only because it could improve the personal measured measured speakers without screwing up the rest any further). I am skeptical though that a mix of personal measured speakers and not personally measured speakers (that can not be optimized independently) will sound very nice, regardless of using manLOUD or not.

 

[Sanctuary]

You create a manLOUD using one specific PRIR, and in fact during that process only information from L+R, or C, or L+R+C (your choice) from that PRIR is used. All manuall changes that you apply to the HPEQ in this process are aimed at improving those front speakers.
Later you use this HPEQ in a preset, where it will apply to all speakers in the used listening room. (Because it is finally just one stereo EQ, applied to the stereo headphone signal after - or maybe I should say as the last step in - the speaker virtualisation process.)
Because it is applied to all speakers, but adjusted to suit the front speakers, the changes are pseudo-random to all the other speakers meaning other speakers could be improved, or get worse, or just different but not better or worse. The idea behind this is that the front speakers are more critical, and hopefully the other speakers won't be screwed up too much!

I think that if the other speakers are from other PRIRs or BRIRs then the chance of getting all speakers to sound fairly realistic will decrease, but still maybe it is worth to try (if only because it could improve the personal measured measured speakers without screwing up the rest any further). I am skeptical though that a mix of personal measured speakers and not personally measured speakers (that can not be optimized independently) will sound very nice, regardless of using manLOUD or not.

Hmm, OK thanks. That did answer one other question I was curious about though. I assumed that when adjusting the speakers via manLOUD that you had to adjust all of them, but you only have to do up to three it appears, which is pretty helpful. This was just going to be a stopgap for me anyway, and while I know it's best to have all speakers personally measured, I was at least wanting to add some heights, even if that only means four and see how that sounds. Also, since subs are non-directional, shouldn't it be fairly easy to get a decent sound from just about any good sub capture, or would the sound of the room still have a high chance of making it sound off?

 

[dsperber]

It kept giving me an error each time I tried to use it. "Failed to open device. The process cannot access the file because it is being used by another process". Happened each attempt, and restarting didn't help either. Ironically, I didn't need it since I already had a partition manager that I haven't needed to use in ages that I forgot about that worked no problem.

Also the latest firmware for the A8 shows 2019 on the file. Was this actually a new update from Revision 3 (2011)? Because that's what mine currently has.

For the A16, I'm assuming they shipped it with the most up to date firmware, but if for whatever reason they didn't, are there currently any new bugs that might have been introduced with it, and should I hold off on updating if so?

I've done a binary compare of the "latest" A8 firmware showing 2019 and it is identical to the 2011 binary file. So if that's what your A8 has in it that's fine. You will know immediately because when you export the files from internal memory to the external SD card the file names will be in the new "*20*" format HPEQ20xx and PRIR20xx. You should be fine.

Your new A16 will arrive with the most up-to-date firmware already preinstalled. It will perhaps be even newer than the most current public download version 2.05 from October 2021.

Now for closure on the GUI Format FAT32 issue, the problem for me (and probably for you as well) is that I'd inserted the microSD card into the USB card reader, and then plugged the USB card reader into the PC (all of which is normal of course) preparing to initialize it. But I hadn't paid close attention to what happened next. Because I use BitDefender as my anti-virus, it automatically kicked off a "device scan" in the background for the newly inserted removable device. It actually starts running the scan automatically in a minimized background process that's not obvious it is running. I had clicked on "X" to close the message box advising of this, rather than clicking on "more details" to actually open up the window showing the device scan progress.

So what was actually going on in the background was a BitDefender device scan of the microSD card. That is why I could not simultaneously use GUI Format FAT32 to initialize it, resulting in the error message both you and I saw.

Not fully appreciating all of this before, and not being able to figure out what "leftover and still-active" process had this "open handle" on the device (especially after I'd gone ahead and physically removed the drive so that now for sure the background device scan could not complete), I just decided to reboot the machine and try the whole thing all over again. And this time I was more aware of what BitDefender was doing.

So now, once again I plugged in the USB card reader with the microSD card to be initialized inserted. And once again, sure enough that BitDefender "background device scan starting" message appeared. But this time I clicked on "more details", to now present the "scan in progress" window which offers a STOP button. This time I pushed the STOP button, got a confirmation requiest asking if I really wanted to stop the scan, I pushed OK, and the scan terminated. I then closed that BitDefender window.

And now, with BitDefender's background removable device scan ended and the BitDefender scan process closed and gone, I once again launched GUI Format FAT32. Once again I entered a volume serial number (i.e. "SMYTH") and then pushed the START button. And this time it ran perfectly, quickly, and without any error message.

I'm sure some similar story happened on your own machine. You perhaps had Explorer open in another window, or maybe whatever anti-virus you have on your PC was similarly doing a background device scan, or who knows what.

But it is now clear that the cause of the earlier program malfunction wasn't caused by the program itself. Rather, it was caused legitimately by some second process currently being active and open and using the device. Only when that process ends or can be killed can GUI Format FAT32 be used (running in "exclusive control" mode, as it needs to be in order to reformat the drive).

Case closed due to user error.