It's the same image. There is only one image url that gets loaded and you can reference it hundreds of times. It won't get loaded again (unless you switch off caching).
I think you missed the point I was making in that when you declare background-image for the second time then all previous versions of that property are reset even if they had multiple images defined. Linear-gradients are essentially treated as background images in most respects.
If you say background-image: img1, img2, img3 (pseudo code) and define three images to start with then you can't set up another rule for the same element and say background-image: img4 without losing img1,2 and 3. You would need to define them again. The fact that you specify them again does not matter because the image was loaded into cache the first time it was seen and is still there so there are no overheads to consider.
I gave you the answer anyway so just run my code and see that it works.
It's the same image no matter how many times you say it!
When you use comma separated images in the background-image property you must restate all the images even if you are changing only one of them subsequently. You are changing the linear gradient so you need to restate and image paths also. If you weren't changing the gradient then you could just change the background-position without the need to reference the url.
The image is only fetched once. On first load the image is loaded into cache and the cached version is used until it expires some time in the future. You can add the url 100 times into your page but the http request will only be once.
That code looks like its part of some image replacement technique where alternative text is available for assistive technologies like screenreaders. Your gradient backgrounds are just decoration and there is no need to clarify their purpose.
The only images of importance in your example will be the play and stop buttons so they are the elements that need some sort of description so that screen readers can tell what their use is. At the moment a screen reader wont have a clue what to do with your inline svg (as far as I know). That's why I prefer to use a real image tag and use the alt attribute to supply the necessary information when an image is content and not decoration.
The 'display' property sets the display of the element (as you well know by now) and doesn't have a bearing on sprites as such.
However if you are trying to apply width and height to an inline element such as a span so that you can apply an image (or image sprite) to it then you would need to change the display as inline elements cannot have dimensions applied (a span is an inline element).
Therefore you would need for example to make the span display:block (if on a line on its own) or display:inline-block (if you want a number on the same line) and that allows the dimensions to be applied (there are other display:values that could be used depending on circumstance).
This is basic css and nothing to do with sprites as such and something we have mentioned numerous times before. (That's it from me today )
It’s because they are using completely different techniques to manipulate the visible part of the image.
The first example uses an inner element of 520px height to hold the sprite so the overflow:hidden on the parent is used to stop all the sprite being visible. The parent is only 260px tall and if the overflow wasn’t hidden the inner span would stick out of the bottom of the parent revealing both portions of the sprite.
It’s a completely different method than the background position manipulation of the second example.