cristian.lorenzetto@: If its still an issue on the latest stable(59.0.3071.86), would it be possible for help with screen-cast of this issue for clearer picture.

Adding respective component for help in better triaging of this issue.

considering firefox team told they wont support mse for mp3 , i removed this feature in the app. Sincerelly the audio stream is a real problem in browsers. No professional solution opensource or simple to implement. Aurora javascript project contains many bugs and is not properly a real streaming solution.  
Sincerely it is a grave error to not support mp3/aac al least. Another grave error (technical) is to design a mediarecorder saving all data in a blob instead to passing chunks: in many mobile devices creates a crash for out of memory. 
MediaRecorder might be a encoder mse compliant for a complete interoperability

Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Cc'ing wolenetz@ for help in better triaging of this.

Tested on Chrome Stable# 59.0.3071.104 & Canary#61.0.3135.0 on Windows 10 and issue is reproducible. This is a Regression in M47 builds. 
Providing the bisect manually

Chrome Good Build -- 46.0.2490.86 (344925)
Chrome Bad Build -- 47.0.2526.106 (352221)

Below is the CL --
https://chromium.googlesource.com/chromium/src/+log/46.0.2490.0..47.0.2526.0?pretty=fuller&n=10000

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/748834c3a5b1b0479835c4cb3ce7d9b9c8302934

 @rtoy Could you please look into the issue, kindly re-assign if this is not related to your changes.

Note: Tested the issue on Mac OS X 10.12.5 and Linux 14.04 and was not able to reproduce the issue.
Per Revision bisect and has bisect script could not provide any possible suspects.
Thank You.

That CL is for webaudio.  Based on the repro instructions, webaudio isn't used, so it seems not relevant.

Unassigning myself.

@wolenetz Could you take a look?

@#6 that's a huge bisect range. I'll try to narrow it.

Hmm -- to narrow the bisect I'd need clearer repro steps. Looking at the original post, it looks like the question may be simply about MSE API.

cristian.lorenzetto@:
> 2. when i reseek at the beginning of song, audio.buffered.start(0) is greater than 0 so algorithm thinks to download a chunk because the buffer is empty
> |  <------------------------>|
> but when chunks are added ... duration encrease because it append new frames. 
> So the behaviour of MSE for mpeg seams different from mp4 container.
> It is a bug or i have to consider a different logic? in the second case what is the logic of mse?"

Short answer: yes, there is different logic to consider for MSE (especially for a bytestream where the registry has 'true' for the 'generate timestamps flag', which is the case for audio/mpeg and audio/aac) since the web app is responsible for understanding the original media's timeline and the intended timeline of the audio element (they do not have to be the same).

The difference between mp3 bytestreams and mp4 container bytestreams is that the latter contain explicit timestamp information used by the MSE API, and the former doesn't and requires the API to construct timestamps. See the logic associated in the spec with https://www.w3.org/TR/media-source/#sourcebuffer-generate-timestamps-flag.

If I understand your use case, this is what is happening:
0) Append a bunch (from the beginning, timestamp=0) of an mp3 to a SourceBuffer.
1) Play a bunch of that buffered media. Say, until currentTime and buffering have progressed enough such that MSE garbage collection (part of the beginning phase of the MSE API implementation for appendBuffer) has removed some previously buffered media from the media element's buffered timeline. This is very likely why your audio.buffered.start(0) eventually increases -- earlier data has been removed to make room for more recent appends.
2) Now, when you are handling a seek to an unbuffered time, you will need to (for any MSE bytestream):
2a) Notify the SourceBuffer about the intended start location for an append that you're about to do to fulfill the seek, and
2b) Append the associated media

In the case of a simple MP4 container, where (in a simple case) we might assume the container's coded frames' presentation timestamps match the intended media element's location of the frames after being appended by the web app, step 2a is not needed.

But for MP3, since the MSE API needs to "auto-generate timestamps", it *assumes* that the append sequence goes forward in time. You can override this, to accomplish 2a, by setting timestampOffset appropriately and coherently with the media that you append in 2b.

So, to handle a seek back to unbuffered time 0, assuming that time is also the intended element timeline of the beginning of your next append, just set your SourceBuffer.timestampOffset to 0 before the append.

I hope this helps. Note that timestampOffset is also useful to relocate intended location of other bytestream appends (like MP4) - the offset is applied to the timestamps in the appended media to determine the resulting location in the element's timeline for each appended coded frame.

Since this seems to be WAI, just an MSE API question, I'll mark this bug as WontFix.

Please re-activate this bug or file a new bug if my understanding of the original bug report is incorrect.