Disclaimer: I don't have one to investigate, and I've not designed one... this is all reasonable speculation that may need some supporting R&D effort to finesse. Images below are taken from the linked video.
But there's definitely more to it, right?
In the sense that it must be receiving an audio stream via bluetooth, probably transcoding it to MP3, and presenting a "well formatted" MP3 file to the car's head unit, yes... but it's probably not much more than that.
A basic filesystem (e.g: FAT32) can be feigned fairly easily without actually storing anything persistent. In this case it appears to have three files each named bt-music.mp3 (a little unexpected due to name conflicts - perhaps the head unit gathered them from multiple directories). If you connect it to a computer, I suspect you'd find they're each presented as large files (a maximum of 4 GB for FAT32) - that would allow the head unit or other reader to read() through the file for quite a long time before it's exhausted (estimated at ~29 hours for a 320kbit/s stream, and it's probably lower than that)... when it reaches the end of one, it'll probably move on to the next.
Now that we've got the presentation sorted, we need to fill the files with something interesting. The feigned file table discussed above will state what offset each file resides at, so the device "knows" which file is being accessed. There will be some "dynamic" content that isn't actually stored anywhere, but is generated automatically - this will contain the streamed audio. There will also be some static content that is probably the same for each file... MP3s use ID3 tags to provide metadata - from what's displayed on the head unit, I'd suggest this has fixed content along the lines of JL and JL-BT-MUSIC for the artist and/or track name. Note also the -16:24:_ time remaining - fun!
The dynamic content just needs to "look reasonable". MP3s can be streamed without seeking through the entire file, which means that the received Bluetooth audio can be transcoded into MP3, and that data can then be presented to the reader via this dynamic region. Again, the data isn't stored anywhere, aside from a small volatile buffer. I fully expect that fast-forward / rewind won't work here, but it's possible that they could implement next / previous track skiping by detecting access to the three files and passing the relevant Bluetooth media control events to the original device.
The interesting ICs are almost certainly these... sadly I can't see the markings clearly to get part numbers.
I think it's a neat and quite usable concept, but I suspect it won't be very robust beyond very basic access and linear playback. The clever bit is all in transcoding the audio and the fake filesystem.
PS: I've just ordered one of these because it looks similar, and I'm curious.
