QT10 Player shows same m4a file at different sizes from different sites

After a week of mucking about, I'll be most grateful for any light shed!

Not a web programmer so I do not know how or why your web code does not override the default physical settings in your file. However, it appears that GarageBand sets both the "Normal" and "Current Display" settings to 160x160 even when you encode the Photo-JPEG content at 300x300. If you really want the images to display at 300x300, you you will have to manually reset the display values.

I also noted that the sample file you referenced only contained one chapter marker ("Start") and is "Hinted" for RTSP use even though the server you referenced does not apper to be an RTSP server. In any event, here is a copy of the modified file:

20111030.m4a

You can check to see if it plays the way you want.

I've taken a quick peek in GB help and online, and so far see nothing about either of those Normal/Current Display settings -- my images have just been pre-sized to 300x300, then dragged into the Podcast Track. When saving the file, I've ensured that the check box is on for limiting image size to the same 300 x 300. Clearly I am missing something about setting the image sizes.

It appears GarageBand employs a more or less fixed output preset for the Podcast "image" track. You do not have to pre-size the images. As long as they are square, GarageBand will re-scale the image and encode it at either 300x300 pixels (with "Set image" switch checked for 300x300) or 160x160 pixels (with "Set image" switch unchecked for 300x300).

As you can see here, your original file (with the image setting checked for 300x300) is encoded as a Photo-JPEG video track at 300x300 pixels but defaults to 160x160 "Normal" and "Current" display dimentsions. I suspect that your web page code was only used when you published to your MobileMe account. In this case the code overrides the display settings embedded in the file giving you the desired display dimensions. Conversely, when you uploaded the file to other Podcast sites, it appears the HTML code was either not uploaded or, if included, was discarded by the hosting site forcing the files to display at the default display dimensions embedded within the file.

The image above depicts the statistics for a GarageBand Podcast I created with the the "Set Image" option unchecked for a 400x768 source image. As you can see the image was scaled and cropped to a 160x160 pixel image not only for the "Normal" and "Current" display dimensions, but the image was actually encoded at the lower 160x160 Photo-JPEG rsolution also.

Lastly, in the case of my modified version of your file, I simply re-set the "Normal"/"Current" display settings to match the encoded 300x300 pixel value. By default, this allows the file to play at the larger resolution in both classic and "new generation" media players since the file is not PAR encoded, as well as, play at the correct size on web pages not coded to override the embedded display dimensions.

I've taken a quick peek in GB help and online, and so far see nothing about either of those Normal/Current Display settings ... May I ask whether you used a different tool to inspect and modify the m4a file? Certainly your outcome is exactly the result I am looking for! If you have a moment to give a little more insight into your method, that would help me along further.

I used the Inspector window in the QT 7.6.6 Player to view the settings in your Podcast file as exported by GarageBand. You could just as easily used the QT X Inspector window but then you would have had to deal with the issue of files not being displayed with a width less than 480 pixels as depicted here:

(NOTE: Actually, the QT 7 Player has a similar problem in that the controller will not display with a width less than 360 pixels even though a video with a width less than 360 plixels will display correctly pillared on a "black" 360 pixel width background. Of course, in the case of the QT 7 Player, the contorller can be turned off rendering the display at the correct dimensions without pillaring.)

With regard to correcting the display problem, the easiest method is to use QT 7 "Pro" to modify the display setting. Of course, this work flow places the data in a new MOV file container which seems to bother some people but does not normally affect playback (other than changing the default "Open with..." application). To avoid this problem, I used the "Dumpster" utility which allows me to examine/modify the contents of "moov" atoms. Unfortunately, this developer utility is somewhat old and I'm not sure if it is still available for downloaded from the Apple "Developer" area.

I assumed that all the commercial podcast-hosting sites would be capable of streaming the content. I gahter this is something I should look for in a hosting solution.

Not sure what your requirements are. RTSP is not really a requirement for most non-commercial users. The main difference is that in RTSP, the media player only plays a temporary cache of data while regular servers cache the entire file locally for playback. For most, "Fast Start" is enough. In this case, the file begins playback as soon as it has cached enough data for continuous playback. As an added note, if you use the QT 7 Pro "Save As..." option to save your "display fixed" files, then it automatically sets the "Fast Start" switch. I believe an RTSP provider will cost more but I have no real experience here as I have always used "Fast Start" files on standard servers like MacDotCom, MyFamily.Com, or MobileMe and am preparing for the more limited iCloud content use.

What the...? I've clearly missed something else. I'm switching to iCloud as well, but I had no idea it could be used to serve content to web pages hosted elsewhere (is that what you mean?). Everything I've [mis?]understood was that iCloud is tightly bound to Apple apps and syncing between devices. I've never seen anything about APIs or links you can set up to collect files in web pages (or any technology outside the supported Apple apps themselves).

If I am not misunderstanding your intent, I wonder if you have a link to some doco where I could read up about iCloud 'serving' content? I could ask no more of you, as you have already been extraordinarily helpful and quickly untangled me from a very nasty spot. For that, my heartfelt thanks. You are a champion!

Sorry about the misunderstanding. Was only referring to the automated sharing of content between my own devices. Tend to spend a lot of time these days in waiting rooms what with ferrying myself, my wife, and my father-in-law to various medical appointments. Luckily, many offices are now equipped with public WIFI hotspots making it easy to work on documents, listen to music, watch movies, and access latest photos. Already have AirVideo internet server, just set up iWork document sharing and Photo Stream, but am still awaiting "iTunes Match" subscription service for music content. Did not mean to imply the iCloud would replace MobileMe's general storage/publishing services. Will still have to move web sites to a new general storage hosting service but have until June 30th of 2012 to set that up. (Believe the savings on the hosting service will more than pay for the iTunes Match subscription.)