Wav To 320 Kbps Mp3

[Deidamia Bassiti]

Idownloaded HDtracks free ultimate down tracks, 24/96 FLAC. When I play them through my NAS and a USB thumb drive, my player shows 3072 kbps. I know that this is 16/96. I called the manufacturer and they said that FLAC has a variable bitrate and the kbps will vary based on the file size and other things. I think this is a load of crap but don't know how to prove it.

I'm sorry but I don't completely understand, if the recording is created 24/96, even if the FLAC is compressed, it is uncompressed at playback, why shouldn't it play back at 4608 kbps. Trying to test my system I thought that if I choose a file that HDtracks was using to show off their capabilities it would take full advantage of the 24/96 and play back at 4608.

1. Does my Marantz NA7004 truly have the capability to play 24/96. I am suspicious because it says that it only plays swav files which are 16/96. Also, isn't 3072kbps exactly 16/96, which is what I got playing the two HDtracks files I tested.

2. I am trying to test that the ethernet cable/ router interface I am using to pull the files from my NAS does not have a bottleneck which might limit the kbps. That is why I tested from the NAS and the USB thumb drive, with the same results.

Again, it depends on the compression. That's determining the number you're reading. It has nothing to do with whether you are getting the equivalent of the playback uncompressed. You are. That simply isn't the number you are seeing.

For heaven's sake: playback bit rate is NOT fix for FLAC and hence cannot have linear relation with bit depth and sample rate. 3072 is not weird at all, customer support was right and you were wrong in thinking it's all crap.

To turn it the other way around a little : tell me how big the chance would be that the 3072 (which *is* 16/96) is coincidentally the compressed rate ? (which would be at the low-compressed side in the mean time)

Does my Marantz NA7004 truly have the capability to play 24/96. I am suspicious because it says that it only plays swav files which are 16/96. Also, isn't 3072kbps exactly 16/96, which is what I got playing the two HDtracks files I tested.

It would be an incredible coincidence for multiple FLACs in the 24/96 sampler bundle to have a compressed bit rate that is exactly two thirds of the uncompressed bit rate. I think your network player is truncating the samples to 16 bits and displaying the resulting uncompressed bit rate of 3072 kbps.

I am arguing that his call to the company (assume he meant HDTRacks) was not full of crap, as he states. FLAC DOES show less bitrate due to compression, period. If his network player is showing 3072kbps on everything then he has decompressed the FLAC file into 16/96, but that's not proving that the demo is 16/96. I own the demo; it's 24/96. Fact.

Edit: network players can do many things to files; Squeezboxes have the ability to decompress at the server or at the client..and also can downconvert, etc..the bitrate would read much differently depending on the settings. If the OP's beef is with the network player then he likely has a downconvert setting (or the mfg is lying)...but I came into this (as did others) assuming his beef was with HDtracks or the "FLAC can read differntly" answer he got, and I have responded according.

I am trying to prove to myself that my Marantz NA7004 network audio player will play the 24/96 flac file and not turn it into a 16/96 file. The literature says that it plays 24/96 but it does not say that it doesn't down convert it.

The player will only play swav files which are 16/96. So I am skeptical until I can prove other wise. This is why I am having they player convert the the flac file from a USB thumb drive inserted directly into the front of the player and also read the same file off the NAS.

I'm trying to set-up a UART channel to forward data from a camera to a Bluetooth module using the UART communication peripheral on the MSP430 Experimenter's Board (using the MSP430F5438). I have set my DCO to reference XT1, and I now have a steady 2457600Hz SMCLK to run my peripherals. Basically I will connect to the camera module using one UART channel, and forward the received image to the BT module using another UART channel. The fastest speed for the BT module is 921.6kbps, so I want to run my system at this speed.

I don't think you are missing anything with respect to programming the UART registers. The problem is the calculated prescale value of 2.67. This indicates you need 8/3 clock cycles per bit. There is no way to do fractional clock prescaling so you must choose either a 2 or 3 for the field value. As you noted, neither of these values give you the needed clock clock rate.

The only way to overcome this issue is to increase the SMCLK rate so the division of the prescale value can have greater resolution. If you can increase the output frequency of the FLL to a value that is closer to an integer multiple of the 921600 baud rate you desire. That is, solve the equation to determine the required clock rate for the wanted bit rate. This gives you

A divider value of 2 with a modulation that temporarily raises the divider to 3 for some cycles, to get 2.6 in the average, will still cause the module to be clocked by 2.4MHz/2 for part of the time. This is exceeding the maximum clock frequency of 1MHz for some of the clock cycles.

Also, for such a small factor, modulation won't really give a usable result. Some bits are sent at 1.2MBd (if the module works at all for this speed), others at 0.8. Which will probably cause any recipient to be confused beyond repair.

I am not incredibly interested in saving power; my main emphasis is in making the communication at 921.6kbps run smoothly. For that reason, I was wondering if you could help me find the best SMCLK speed for this configuration to work. I also need help to set-up the UCS module with the required clock speed. MCLK and SMCLK can run at the same speed, and preferably from the 32kHz crystal so that it is precise. I followed TI's example code so set up for 2.45Mhz, but I don't know how to get it to work with higher speeds (simply changing the multiplier does not seem to produce a clean signal).

Once again thanks for the help with this topic! I will try to follow the last suggestion of using a multiplication value of 450 for my FLL loop. This will give me a clock speed of 14.7456MHz, which works fine with the online tool developed by Dung to calculate the dividers. Using that tool, I can easily find the values for the UART set-up.

However, I would like to ask for help in setting up the UCS for that desired speed. What should be the values for the Control Registers in the UCS so that I get a clean clock cycle rather than skewed (which is my problem now: I believe it has something to do with the internal capacitance choice and other values in control registers). I am new to this kind of set-up, and would appreciate any help!

So let's say the two available DCO frequencies are 16MHz and 13MHz and you want 15MHz. So teh DCo will be clocked with 16MHz for two and with 13MHz for one cycles (modulation pattern, see the chapter in the user guide), resulting in an average of 14.857MHz over three clock cycles. The modulation patterns have not 3 but rather 32 steps, so you get much closer, but over a longer period of time. If the clock you need (e,g, as bit clock) is by a factor of 16 smaller (the modulation patterns are somewhat symmetrical), you won't notice this jitter much, and with a divider of 32 not at all.

So with your baudrate which runs on 14MHz/16, you could try to go for an FLL divider of 900, put a /2 divider in for teh DCO frequency itself, and then after the /16 of the baudrate generator you won't have any jitter anymore.

At least not during an FLL period: on the next FLL reference clock pulse, teh FLL will decide whether the selected frequency is too low or too high (it will seldom fit exactly) and then adjus the modulation pattern one step up or down or, if modulation was at min/max, a different DCO tap is selected. Which will introduce a small clock jitter again.

attached is the preliminary version of the 5xx core library, which provides api calls to configure core peripherals of any 5xx/6xx devices. The core peripherals include: CPU, PMM, UCS, SVS. You can use the UCS calls to fully configure the clock systems. Other APIs are worth using as well. Unless you know absolutely everything there is to know about the '430 [Jens :p] especially how to bring up the 5xx system, I'd strongly recommend using these provided functions to configure your device.

Maybe I'm still a bit biased from working with the 1232 and its tiny 8k flash and 256 bytes ram: Each time I had to implement a new function I had to see where I can save another byte in the code, eliminate a function call etc. Using libraries for the init would have blasted the available flash more than quickly.

But until you get used to handling this stuff on your own, libraries are okay.

To fully understand the code (e.g., why you set the SVS low side check before changing VCORE, why you check the flag afterwards, etc.) I'd still take a look at the 5xx User's Guide to compare and contrast.

The only issue I have is when looking at the signal on the oscilloscope. The clock looks more like a sawtooth than a clean square pulse. I thought it was capacitive error, so I played around with the XCAP bits in the UCSCTL6 register but couldn't get rid of this effect. On the TI provided sample code, I noticed that the 12MHz DCO example (msp430x54x_UCS_3.c) also produces this kind of output. Is this acceptable?

Also, most oscilloscopes have an input capacitance which may not be ignored! This is why you cannot measure a crystal frequency directly at the crystal with a typical oscilloscope tip. Its capacitance will bring the crystal to a sudden halt.

3a8082e126