I hope this is the right forum.
I'm currently working on creating mka audios that contain an AAC stream, an Opus stream, and a SRT stream. Purpose is for people who are hearing impaired but still benefit from audio, they just need captions to help them make out some of the words. The AAC and Opus streams are same content, it's just AAC decoders are not included out of box on some operating systems (those usually have Opus at this point)
Anyway - figuring out Matroska tags took a little effort but I can finally generate an xml python that when added to the MKA makes sense when I view it in VLC - I have one Tag TargetTypeValue of 70 that has metadata about the collection and one tag with a TargetTypeValue of 30 that is specific to the track itself.
But I want to also add replay gain data, and my understanding is that proper replay gain may vary from lossy format to lossy format, so I can't just add the replay gain data to the Tag node with TargetTypeValue 30.
I'm guessing I have two add to more Tag nodes, one specific to the AAC and one specific to the Opus. That would also let me store the encoder information. But I have trouble with the Matroska tag documentation, it is very confusing.
How do I create a Tag node that adds metadata specific to the AAC stream (always first added) and another one specific to the Opus stream (always second added)?
Thank you for suggestions.
Last post by Mr.Fox -
Cuetools does not understand "REM COMPILATION" from the cue file and "part of a compilation"
no offense - english is not my first language either - but I have no idea what you mean with some of the above...
As for the discogs style question - to me it sounds like you want to reformat a field, and pump the value with different formatting into another field... (?). For something similar, I use this and find it the most convenient:
Hope this helps.
I keep looking worthy upgrades to my favorites Sony MH1 and LG Quadbeat 3. They costed me about 15$ each.
USB is a differential transmission line. Meaning the the data is sent on both the D+ and D- wires at the same time. On the receiving side, the D- line is inverted, then summed with D+ and that's the signal that's being decoded.
Since USB is digital, it's best to think of it in terms of data.
USB cables have two common failure modes:
1. they cannot carry enough current on the Vcc and GND lines (this is often plainly obvious with phones being charged very slowly, etc).
2. Improper shielding and/or improper twisting of D+ and D-. Both of which introduce noise into the signal and hence may or may not corrupt data, in the sense that the differential signal is not decodable.
Should failure mode 1 occur: when your playback device is powered by USB, then it simply won't work, because there's not enough power going to your player, or amp, or whatever.
Should failure mode 2 occur: if the data is undecodable since the levels aren't discernable, the host (USB is always host controlled) will probe the USB device a couple times, and if that doesn't succeed, the device will be rejected.
Host controllers must cut power to the device should the enumerator be unable to probe the device. If you plug in something like a mouse into a USB port very slowly, you'll see the mouse LED or laser switch on, then off, then on again. This is because while inserting the mouse your connection is intermittent. The host controller then cuts power. The controller will then usually give the device another chance to see if the connection has been settled down, this is usually with a 1sec delay, to allow for someone to actually plug a device in, as USB is hot-pluggable by design.
Should this fail a couple more times (usually 12 times for some reason), the host will permanently cut power, and only retry after it sense that the device has been unplugged, and re-plugged. The controller now assumes that another device has been plugged in.
Up to this point, the device hasn't even been attached to the bus by the enumerator.
USB is a logically enumerated device bus, even though it says "bus" in the name, the bus is a logical bus, not a physical one, like with SCSI, for instance. All devices are connected directly to the host controller, and only the controller may initiate data transfers (hence, host controlled). Enumerated means, that the devices are only ever attached to the (logical) bus, when the host controller is able to attach the device at the enumerator. I.e. you can't send data via USB "in the blind" like on an RS-232 line. When the host controller is unable to poll the device on the other end, even though "something" is plugged in, it won't show up to the enumerator, meaning it doesn't exist on the bus.
Before data is being send to the attached device by the host, a set of commands are sent by the host controller. The device on the other end must either accept or reject packets based on their CRC checksums. the ACK or NAK replies are then sent back to the host, the host might want to re-transmit that packet.
If you're using an un-shielded, untwisted USB cable, it will basically require frequent re-transmissions, assuming the noise is not high enough to completely make the signal illegible to the controller. For instance, you're running the bare D+ and D- wires of the USB cable next to a switchmode power supply, and it just induces the right high-enough levels for a host controller to incorrectly assume they're data. In this edge-case the USB connection will seem to be very slow. In this case USB behaves much like Twisted-Pair network cables, as should be evident.
Now, what if that data is PCM audio? Well, if the host controller cuts power and detaches the device from the enumerator, you'll hear nothing, as the device is essentially removed from the host - as saratoga noted correctly.
If communication over said USB line necessitates frequent retransmissions, the USB connection will seem to be slow. So either the sound will be choppy, like streaming from a very slow source, like on very slow internet, or it will buffer forever. Usually, timeouts on USB are rather short, though. So even though the USB will work on the enumerator side, it will give up after a couple tries, and simply let the devices on either end handle error notification, etc.
On controlled digital lines, whether it's USB, or twisted pair networking or what have you, introducing noise into the signal transmission simply means the line gets slower. Down to the point where zero packets reach the other end before either side gives up requesting re-transmissions or re-transmitting itself.
Long story short: What does a bad USB cable sound like? The same a slow or choppy internet connection sounds like.
Incorrect data is always rejected, never simply forwarded no matter what, similar to packets over TCP/IP networks. You either receive the packet, or the NIC rejects it. Same with USB, the host or the slave either accept the packet when it passes its CRC, or reject it. And if the host gathers too many such errors, it might simply decide to remove the device from the bus when control commands are rejected, too.
not every track is worth keeping in 5 or so slightly different versions. as long as they have replaygain it should not be a problem.
Last post by orangefx -
i have my library write protected. changing files in foobar wont work. i am looking for a command to remove, and after applied changes reinstate write protection of marked files.
florians old foo run component could be doing this. but i did not manage to get it to work with attrib.exe -r/+r.
Anyone hoping a new version of this component ?
Requested functionnality : to have the stream title to display dynamic information like %title% or %artist% or both ?
Thanks in advance
@gix : yes - TheQwertiest has right - please issue a new thread on forums. I have some feature request, as this plugin misses certain functionality from original one (blocking tracks from being scrobbled, based on tags)